Re: [MirageOS-devel] OPW intern checking in!

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 10 Jun 2014, at 12:29, Balraj Singh <balraj.singh@xxxxxxxxxxxx> wrote:

> Hi Anil,
> 
> Just to confirm what I was showing you yesterday.  
> 
> This, along with possibly a few other defects, crept in as part of the 
> changes that were made on Jan 23, "Simplify the listener mechanism to push it 
> into the TCP input handler".  The changes were all good improvements, and 
> necessary, but this bug sneaked in.  

Thanks for tracking these down.  I believe this only affects the server side 
(which confirms Mindy's findings), and were due to lifting out some 
datastructures in the listening code, and making them available to the 
application directly.

A short-term fix is probably around making the connection callback an option 
type again, but it would be better to make this more explicit to avoid the same 
mistake in the future.  i.e., instead of

type t = int option
type t = [ `Connection of int | `Connection_being_established ]

the latter is obviously much clearer.

> 
> Mainly, as you say, this points to a lack of good regression tests and test 
> infrastructure.  I have tried to make some unit tests but for TCP there are 
> many balls that have to be kept in the air and I could not quite do it in an 
> automated way.  The most successful of this kind of test was one in which a 
> single VM would bring up 2 virtual interfaces and send specific patterns of 
> data in both directions.  It knew what to expect and it could, if necessary, 
> even examine the state machines of the two TCPs.  This was quite fragile - it 
> would often stumble on something simple like bringing up two VIFs.  

The other option here is not to use Xen for testing the net stack at all, but 
just use Linux with two tap interfaces.  That gives us the ability to use 
tcpdump to inspect the traces as well...

> On 2 Jun 2014, at 17:00, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:
> My first thought is that I don't know how to get the workflow I've been using 
> (start up a unikernel in Xen and throw a bunch of stuff at it from scapy) set 
> up in Travis, but if that doesn't seem like obviously the wrong thing to do, 
> I can look into it.  I would still like to look at Quickcheck as well.

Similar to answer to Balraj above -- instead of spinning up a Xen VM, spin up a 
user-level stack on Linux instead (using `NET=direct mirage configure --unix` 
in the various skeleton examples).

However, one downside to Travis is that it uses LXC (containers) for its 
isolation, and so doesn't support tuntap.

This does leave Balraj's suggestion as the best one: create two network stacks 
in one Mirage program and get them talking to each other!

> 
> Also, an update - Last week I wrote up another Treaty of Westphalia on 
> finding a TCP bug and made Mirage implementations of chargen, discard, and 
> echo for use in testing the TCP stack more directly. Today, I'm planning on 
> getting a whole bunch of data from them and (I hope) finding some interesting 
> results.

The chargen/discard/echo sounds very useful indeed -- how about adding those 
directly into mirage/mirage-tcpip in a lib_test/ (or examples/) directory?

-anil


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel