One other possible use for the bridge might be to adapt a non-ethernet network in gem5 to the ethernet network tap expects? I suppose it could do other forms of translation too, as necessary.
Gabe On Wed, May 31, 2017 at 8:44 PM, Gabe Black <[email protected]> wrote: > Hello folks, I think specifically Nate. I have a need to get EtherTap > working again, and after a lot of digging around and looking at this > conversation from 5 years ago: > > http://thread.gmane.org/gmane.comp.emulators.m5.devel/14675 > > I've made some progress understanding how to do that. I think one of the > big remaining questions I have is why there was an extra program which > opened the tap device and sent the packets to gem5 over a TCP socket > instead of gem5 just opening the tap device itself and doing the reading on > its own. That would certainly be simpler, at least as far as I can tell > with admittedly not a great deal of expertise to work with. > > There are a couple potential reasons I could think of. First, it could > have been a permissions thing. It looks like you need special magical > permissions to create a tap device, and it sounded from that (and this > http://gem5.org/Nate%27s_Wish_List) that folks understandably didn't want > to have to run all of gem5 as root just to get that part to work. Doing a > bit more research, it looks like you can use tunctl to create a persistent > tap device and give it to a particular user. Then that use can open and use > the device without having to be root. root would still need to configure > the device, but that would seem to mitigate that issue. > > The other reason could be that the ioctls, etc., needed to create and > interact with tap devices varies between OSes, and folks didn't want to tie > the implementation to any particular OSes scheme. In that case, the little > bridge program could do the right dance for the OS in use, and then > communicate to generic gem5 over the TCP socket. It could even be that a > tap style interface doesn't even exist on a particular OS, and so the > bridge has to do some other fancy trick to get and receive ethernet frames > from the OS. > > This seems like a harder problem to address, although is there really a > big group of people out there that would use ethernet bridging on a > non-Linux OS? Maybe? It would be nice to exclude people by design, if > possible. > > In the email thread I linked to above, the author said they were using > socat to connect between the tap device and gem5. I'd never heard of socat > before and this almost works, except that gem5 expects the size of the data > to appear at the start of the data it gets over port 3500. Since socat > doesn't do that, gem5 thinks the data size is something ridiculous and ends > up waiting to accumulate enough data before sending the incoming frame into > the network. Similarly, it puts the size at the start of the data its > sending, and I think that confuses socat. Surprisingly I think some DHCP > discover packets make it onto the network, but sometimes socat gets upset > and dies because of an "Invalid argument". I think socat just isn't the > right tool for this job, especially considering how it explodes when > certain admittedly incorrect things are sent its way it's not expecting. > > > Anyway, I can forge ahead doing whatever seems best to me, but I figured > I'd ask for suggestions in case anybody really wanted things done one way > or another for some reason. Let me know! > > Gabe > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
