Re: Current state of the UNIX backend

["Vincent B." <vb@xxxxxxxxx>]

On 27/05/2013 12:30, Vincent B. wrote:
> On 26/05/2013 10:51, Anil Madhavapeddy wrote:
> > So a much easier way to debug this sort of issue is to build a unit
> > test that expresses the desired behaviour first.  I put a small packet
> > dumper for tuntap in:
> >
> > https://github.com/avsm/ocaml-tuntap/blob/master/test/nonblock_read.ml
> >
> > You can build this without any other dependencies by:
> >
> > $ make
> > $ ocamlbuild _build/test/nonblock_read.native
> > $ sudo ./_build/test/nonblock_read.native
> The second command does not work for me, I’m going to try anyway.
> Note that in your test you always use opentun instead of opentap,
> normally this would create a level3 interface instead of a lever2 one.
The command was
$ ocamlbuild test/nonblock_read.native

of course. Apart from that,

> > and if you ping the new interface, you should see hexdump packets on
> > the console.  I do see these on both MacOS X and Linux successfully.
> > If Mort does too, I'll be convinced it actually works :-)
I don't see anything in the console, strangely.

> > And now the question is why the Mirage libraries are different.  I'm
> > guessing it's to do with setting the non-blocking flag, which is done
> > via a stub at the moment.  If you make the behaviour of Ethif match
> > that of my test case, then it should spot the problem.
> >
> > PS: I also noticed that the netmask on the tap0 when you ifconfig is
> > "0xff000000", which isn't the same as the "0xffffff00" I was trying to
> > set it to.  It didn't matter for this test, but should be fixed too or
> > else risk network routing heisenbugs...
Strangely again, for me the mask is set correctly (Linux):


5: tap0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc 
pfifo_fast state UNKNOWN qlen 500 

    link/none 

inet 10.11.12.1/24 scope global tap0

I can ping it correctly, but I don't see anything in the console.

Cheers,

Vincent