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

[David Sheets <sheets@xxxxxxxxxxxx>]

On Tue, Jun 10, 2014 at 11:23 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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.

Last I saw, Travis uses OpenVZ which was an LXC/namespaces/cgroups
precursor provided by a (very) large kernel patch. Privileged LXC
containers (started by a privileged user) do support tuntap if the
executor allows the dev node to be created with something like:

lxc.cgroup.devices.allow = c 10:200 rwm

See also <https://www.kernel.org/doc/Documentation/cgroups/devices.txt>.

I'm not sure if this satisfies your use case but, on its face, it
looks possible.

ds

> 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

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