very odd behaviour using 4.00.1+mirage-unix

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

hi all;

i am seeing very odd behaviour using the unix direct networking stack on linux 
via eg., mirage-www. 

on osx, using "opam switch 4.00.1+mirage-unix", when i "sudo make run" in 
mirage-www, all is fine -- the webserver runs, i can browse to 10.0.0.2:80, 
retrieve pages, etc. no problems. similarly using "opam switch 4.00.1" and 
browsing to localhost:80. 

when i do the same thing on linux, everything is fine under "opam switch 
4.00.1" -- i can browse to localhost:80 without problems. 

but if i "opam switch 4.00.1+mirage-unix", browsing fails -- nothing listening 
on 10.0.0.2:80 (i get a TCP RST). this occurs with ubuntu 12.04 running linux 
3.2.0-23 on top of virtualbox on a mac or on windows; and on ubuntu 10.04 
running linux 2.6.32 as a dom0 on xen 4.1 pvops.

investigating so far, it seems that the tap0 interface is created and given the 
ip address 10.0.0.2; and an appropriate route table entry is created:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        *               255.255.255.0   U     0      0        0 tap0

...but when i examine the route cache, it seems to have mapped 10.0.0.2 to lo 
rather than tap0:

vagrant@precise64:~$ ip route show cache | grep -A1 10.0.0.2
local 10.0.0.2 from 10.0.0.2 tos lowdelay dev lo
    cache <local>
--
10.0.0.2 from 10.0.0.2 tos lowdelay dev lo
    cache <local>
local 10.0.0.2 tos lowdelay dev lo  src 10.0.0.2
    cache <local>

tcpdump bears this out -- the SYN is visible on lo not on tap0.

i have also tried this with linux 3.7 on virtualbox/osx as that kernel rev 
removed the route cache, but see the same brokenness. looking at all routing 
tables, everything seems in order:

vagrant@precise64:~$ ip route list table all | grep 10.0.0.2
10.0.0.0/24 dev tap0  proto kernel  scope link  src 10.0.0.2
broadcast 10.0.0.0 dev tap0  table local  proto kernel  scope link  src 10.0.0.2
local 10.0.0.2 dev tap0  table local  proto kernel  scope host  src 10.0.0.2
broadcast 10.0.0.255 dev tap0  table local  proto kernel  scope link  src 
10.0.0.2
 
however tcpdump shows the same results as before -- the TCP SYN is visible on 
lo not on tap0, and gets a RST in response as a result.

pinging 10.0.0.2 in all cases works just fine, presumably because that's being 
dealt with in-kernel and isn't hitting whichever part of the network stack that 
is confused.

all-- has anyone else seen any problems like this using mirage-unix on linux, 
or does it all just work for you? i don't have a box that's just running 
vanilla linux on the metal without some form of virtualisation to test that -- 
any chance someone else does?  is it possible it's specifically a 
tuntap/virtualisation problem?

vincent-- i understand you're working on ocaml tuntap bindings?  any chance 
they might have some unit tests and are available yet -- i think that would 
really help me try to debug this...


-- 
Cheers,

R.




--
Scanned by iCritical.