Sometimes on a core-image-sato qemu image (which uses connman) I cannot ping/connect to any network address other than the host 192.168.7.1, thus forwarding seems to be broken sometimes. core-image-minimal does not seem to be affected, nor does core-image-sato on atom-pc. I've reproduced this intermittently on both a qemumips, qemux86-64 and qemux86 images, however it seems more likely to occur on the qemumips image (which incidentally I am running remotely over ssh from another machine, thus it is slower). The behaviour leads me to believe it is a timing issue. Possibly unrelated, but it does seem that connman behaves slightly differently on the emulated network interface which is set up from boot as opposed to a real ethernet adapter on atom-pc - e.g. within qemu the connman applet doesn't show the network as connected until quite a while (up to 30s) after it starts, whereas on atom-pc it immediately shows as connected.
Is this tap/tun or something else, please update
This would be via tun/tap yes, when running an ext3 image via runqemu. My first plan of attack was going to be to compare the outputs of "route -n" when working and not working; I haven't got to that yet.
(In reply to comment #0) > Sometimes on a core-image-sato qemu image (which uses connman) I cannot > ping/connect to any network address other than the host 192.168.7.1, thus > forwarding seems to be broken sometimes. core-image-minimal does not seem to be > affected, nor does core-image-sato on atom-pc. > > I've reproduced this intermittently on both a qemumips, qemux86-64 and qemux86 > images, however it seems more likely to occur on the qemumips image (which > incidentally I am running remotely over ssh from another machine, thus it is > slower). The behaviour leads me to believe it is a timing issue. Possibly > unrelated, but it does seem that connman behaves slightly differently on the > emulated network interface which is set up from boot as opposed to a real > ethernet adapter on atom-pc - e.g. within qemu the connman applet doesn't show > the network as connected until quite a while (up to 30s) after it starts, > whereas on atom-pc it immediately shows as connected. Hi Paul, When you see the issue, can you please run "echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp" (change tap0 to the actual one if it's not tap0) in the host with root privilege, and please use IP address directly to exclude any possible DNS issue? I recently noticed the similar issue (I suppose it's similar) -- I can always reproduce the issue on qemux86 and I work it around by enabling the proxy_arp and cat my host's resolv.conf into the qemu guest's one. I remember vaguely long ago I didn't have such an issue.
(In reply to comment #3) > (In reply to comment #0) > > Sometimes on a core-image-sato qemu image (which uses connman) I cannot > > ping/connect to any network address other than the host 192.168.7.1, thus > > forwarding seems to be broken sometimes. core-image-minimal does not seem to be > > affected, nor does core-image-sato on atom-pc. > > > > I've reproduced this intermittently on both a qemumips, qemux86-64 and qemux86 > > images, however it seems more likely to occur on the qemumips image (which > > incidentally I am running remotely over ssh from another machine, thus it is > > slower). The behaviour leads me to believe it is a timing issue. Possibly > > unrelated, but it does seem that connman behaves slightly differently on the > > emulated network interface which is set up from boot as opposed to a real > > ethernet adapter on atom-pc - e.g. within qemu the connman applet doesn't show > > the network as connected until quite a while (up to 30s) after it starts, > > whereas on atom-pc it immediately shows as connected. > Hi Paul, > When you see the issue, can you please run > "echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp" (change tap0 to the actual > one if it's not tap0) in the host with root privilege, and please use IP > address directly to exclude any possible DNS issue? > > I recently noticed the similar issue (I suppose it's similar) -- I can always > reproduce the issue on qemux86 and I work it around by enabling the proxy_arp > and cat my host's resolv.conf into the qemu guest's one. > > I remember vaguely long ago I didn't have such an issue. I suppose the patch in poky master has fixed this bug? http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0f95925b4cdc39a40969f7e496c3924fa91f61c6
No, that patch only fixed the issue in core-image-minimal, which doesn't use conman. What I found is that external network access works for about the first 30 seconds or so after a -sato image boots up, then external network access stops working. So I suspect that there is something conman is doing to change things - though I have yet to confirm this.
(In reply to comment #5) > No, that patch only fixed the issue in core-image-minimal, which doesn't use > conman. What I found is that external network access works for about the first > 30 seconds or so after a -sato image boots up, then external network access > stops working. So I suspect that there is something conman is doing to change > things - though I have yet to confirm this. Though I'm not familiar with iptables and the tap device, with the following patch aplied, I do make the network in qemu sato image work . :-) BTW, however the DNS resolver in qemu sato still doesn't work as expected -- I have to use IP address directly, or scp my host's /etc/resolv.conf into the qemu target. Maybe you can try this when you get the issue with connman in qemu sato. Hope this can be a clue to the final fix. diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup index f80538f..1f1b4c8 100755 --- a/scripts/runqemu-ifup +++ b/scripts/runqemu-ifup @@ -103,6 +103,7 @@ $ROUTE add -host 192.168.7.$dest $TAP $IPTABLES -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.$n/32 $IPTABLES -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.$dest/32 echo 1 > /proc/sys/net/ipv4/ip_forward +echo 1 > /proc/sys/net/ipv4/conf/$TAP/proxy_arp $IPTABLES -P FORWARD ACCEPT echo $TAP
Thanks! I'll check that out.
Fixed in poky denzil as of: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=denzil&id=309b2c090ed25df35457225e041e5e37976dd9f8