[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

very odd behaviour using 4.00.1+mirage-unix

  • To: cl-mirage List <cl-mirage@xxxxxxxxxxxxxxx>
  • From: Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>
  • Date: Tue, 19 Mar 2013 16:06:22 +0000
  • Accept-language: en-US, en-GB
  • Acceptlanguage: en-US, en-GB
  • List-id: MirageOS development <cl-mirage.lists.cam.ac.uk>
  • Thread-index: Ac4ku7OIR6cljfW/Q5ORPbx7WZiM1g==
  • Thread-topic: very odd behaviour using 4.00.1+mirage-unix

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, 
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 (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; and an appropriate route table entry is created:

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

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

vagrant@precise64:~$ ip route show cache | grep -A1
local from tos lowdelay dev lo
    cache <local>
-- from tos lowdelay dev lo
    cache <local>
local tos lowdelay dev lo  src
    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 dev tap0  proto kernel  scope link  src
broadcast dev tap0  table local  proto kernel  scope link  src
local dev tap0  table local  proto kernel  scope host  src
broadcast dev tap0  table local  proto kernel  scope link  src
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 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...



Scanned by iCritical.



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.