Ok, thanks. I'll give that a try. Gabe
On Thu, Jun 1, 2017 at 9:03 AM, Jason Lowe-Power <[email protected]> wrote: > Hi Gabe, > > I also did some work trying to revive ethertap recently. I think it would > be *really cool* to get gem5 to be able to easily talk to the outside > world. I think that it is worth it for this to only work on one platform. > If someone else comes along and wants to extend it to other, they can do > that then. > > Overall, I came to similar conclusions as you did. Piping everything > through socat is at least mildly broken, and it makes more sense go > straight through the tap/tun device. > > My initial thought was to copy the way qemu sets up a network bridge. But I > never really dug into it enough to fully understand how the qemu code > works. > > Below are the notes that I took while I was trying to get it to work > (mostly just a knowledge dump so you may or may not be able to get anything > new out of it). The code I have is based on the old mercurial repo, so it > will take me a little time to clean it up so it applies cleanly and works > with the current mainline. I'll try to do that this weekend. > > I ended up getting it mostly working, except for the socat issues that you > have run into. If I ran socat in a while loop (shown below) the > gem5->internet connection would eventually get all of the data since the > socat link re-established itself. > > Cheers, > Jason > > > Getting networking going > ======================== > > To do > ----- > Figure out why it works with fs.py but not with my config files. Ugh! > > > Disk changes > ------------ > To get things to work in ubuntu, you have to add the device to > /etc/network/interfaces. > > To find the device name, run ifconfig -a > > .. code-block:: sh > > ifconfig -a > > .. code-block:: > > enp0s0 Link encap:Ethernet HWaddr 00:90:00:00:00:01 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:3420 (3.4 KB) > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:65536 Metric:1 > RX packets:1760 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1760 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1 > RX bytes:130240 (130.2 KB) TX bytes:130240 (130.2 KB) > > Mine was "enp0s0". > > Update /etc/network/interfaces with the right device name: > > .. code-block:: > > auto enp0s0 > iface enp0s0 inet dhcp > > > On the host to enable a bridge > ------------------------------ > Create a bridge. This is the script I used. > Saved the script as qemu-ifup, and I ran "sudo ./qemu-ifup". > > .. code-block:: sh > > #!/bin/sh > # > # Copyright IBM, Corp. 2010 > # > # Authors: > # Anthony Liguori <[email protected]> > # > # This work is licensed under the terms of the GNU GPL, version 2. See > # the COPYING file in the top-level directory. > > # Set to the name of your bridge > BRIDGE=br0 > > # Network information > NETWORK=192.168.53.0 > NETMASK=255.255.255.0 > GATEWAY=192.168.53.1 > DHCPRANGE=192.168.53.2,192.168.53.254 > > # Optionally parameters to enable PXE support > TFTPROOT= > BOOTP= > > do_brctl() { > brctl "$@" > } > > do_ifconfig() { > ifconfig "$@" > } > > do_dd() { > dd "$@" > } > > do_iptables_restore() { > iptables-restore "$@" > } > > do_dnsmasq() { > dnsmasq "$@" > } > > check_bridge() { > if do_brctl show | grep "^$1" > /dev/null 2> /dev/null; then > return 1 > else > return 0 > fi > } > > create_bridge() { > do_brctl addbr "$1" > do_brctl stp "$1" off > do_brctl setfd "$1" 0 > do_ifconfig "$1" "$GATEWAY" netmask "$NETMASK" up > } > > enable_ip_forward() { > echo 1 | do_dd of=/proc/sys/net/ipv4/ip_forward > /dev/null > } > > add_filter_rules() { > do_iptables_restore <<EOF > # Generated by iptables-save v1.3.6 on Fri Aug 24 15:20:25 2007 > *nat > :PREROUTING ACCEPT [61:9671] > :POSTROUTING ACCEPT [121:7499] > :OUTPUT ACCEPT [132:8691] > -A POSTROUTING -s $NETWORK/$NETMASK -j MASQUERADE > COMMIT > # Completed on Fri Aug 24 15:20:25 2007 > # Generated by iptables-save v1.3.6 on Fri Aug 24 15:20:25 2007 > *filter > :INPUT ACCEPT [1453:976046] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [1605:194911] > -A INPUT -i $BRIDGE -p tcp -m tcp --dport 67 -j ACCEPT > -A INPUT -i $BRIDGE -p udp -m udp --dport 67 -j ACCEPT > -A INPUT -i $BRIDGE -p tcp -m tcp --dport 53 -j ACCEPT > -A INPUT -i $BRIDGE -p udp -m udp --dport 53 -j ACCEPT > -A FORWARD -i $1 -o $1 -j ACCEPT > -A FORWARD -s $NETWORK/$NETMASK -i $BRIDGE -j ACCEPT > -A FORWARD -d $NETWORK/$NETMASK -o $BRIDGE -m state --state > RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -o $BRIDGE -j REJECT --reject-with icmp-port-unreachable > -A FORWARD -i $BRIDGE -j REJECT --reject-with icmp-port-unreachable > COMMIT > # Completed on Fri Aug 24 15:20:25 2007 > EOF > } > > start_dnsmasq() { > do_dnsmasq \ > --strict-order \ > --except-interface=lo \ > --interface=$BRIDGE \ > --listen-address=$GATEWAY \ > --bind-interfaces \ > --dhcp-range=$DHCPRANGE \ > --conf-file="" \ > --pid-file=/var/run/qemu-dnsmasq-$BRIDGE.pid \ > --dhcp-leasefile=/var/run/qemu-dnsmasq-$BRIDGE.leases \ > --dhcp-no-override \ > ${TFTPROOT:+"--enable-tftp"} \ > ${TFTPROOT:+"--tftp-root=$TFTPROOT"} \ > ${BOOTP:+"--dhcp-boot=$BOOTP"} > } > > setup_bridge_nat() { > if check_bridge "$1" ; then > create_bridge "$1" > enable_ip_forward > add_filter_rules "$1" > start_dnsmasq "$1" > fi > } > > setup_bridge_vlan() { > if check_bridge "$1" ; then > create_bridge "$1" > start_dnsmasq "$1" > fi > } > > setup_bridge_nat "$BRIDGE" > > if test "$1" ; then > do_ifconfig "$1" 0.0.0.0 up > do_brctl addif "$BRIDGE" "$1" > fi > > After starting gem5, I ran the following socat command to create a tap > device and > connect it to the bridge. > > .. code-block:: sh > > while :; do > socat -s TCP:localhost:3500,forever TUN: > 192.168.53.1/24,up,tun-type=tap,user=powerjg & > brctl addif br0 tap1; > fg; > done; > > It's wrapped in a while loop because there are lots of errors and it needs > to be > restarted every time there is an error. > > You may want to use -d -d -d as the option to socat to output more > information. > Also, I want to modify this so that it waits for the socket to be > connected. > I think that's possible. > > On Wed, May 31, 2017 at 10:57 PM Gabe Black <[email protected]> wrote: > > > 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 > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
