Re: [MirageOS-devel] Problem http reply with mirage-static and mirage-www

[Luis Oviedo García <psxlco@xxxxxxxxxxxxxxxx>]

________________________________________
From: mirageos-devel-bounces@xxxxxxxxxxxxxxxxxxxx 
[mirageos-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Richard Mortier 
[richard.mortier@xxxxxxxxxxxx]
Sent: Sunday, June 07, 2015 4:25 PM
To: Carlos Oviedo; Thomas Leonard; David Scott; Balraj Singh
Cc: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [MirageOS-devel] Problem http reply with mirage-static and 
mirage-www

On 7 June 2015 at 16:11, Carlos Oviedo <luis.oviedogc@xxxxxxxxx> wrote:
>> The first ACK of the unseen segment looks really weird to me -- did
>> wireshark report drops? What version of mirage-tcpip are you using? If
>> the latest, might be worth trying to back off (via opam pin) as
>> there've been changes recently that may be having subtle effects...
>
> Wireshark reports unseen ACKed unseen segments and duplicated acks,
> wondering if it is only me who sees this weird behaviour.
> Using the latest version (2.4.3), will try as suggested.
>
>> (Possibly also easier for others to read if you just capture a binary
>> .pcap file and attach that -- quite hard to parse the text output in
>> an email like that, for me at least!)
>
> Attached :)

Hm-- the ACK that completes the handshake appears to have the spurious
trailing 6 zero bytes. Because these 6 bytes aren't expected, they're
not actually given in the sequence number space (sent in a segment
from .104 with ACK=true, seqno=1, ackno=1), and so when the server
(.114) explicitly ACKs (ACK=true, seqno=1, ackno=7) them, things
subsequently get confused with duplicate ACKs, apparently spurious
retransmissions, etc.

This is a bit weird because the client is CURL which one assumes is
using the local stack which ought to be roughly correct (!)

Carlos-- what exactly is the experimental setup here -- hosts, VMs, IP
addresses, kernel versions, etc?

I have two setups, both experiencing the same problem:
- The local one is using my home router as dhcp server, my laptop as xenhost 
(3.16.0-38-generic, 192.168.1.113), xen-unikernel (192.168.1.114) and my 
android phone as client (kernel version 3.4.0 if it matters, using either a 
terminal emulator or client browser, 192.168.1.104)
-The "prodcution" one, which is using the CS school network, uses a to 
xenserver machines (both kernel version 3.10.0+2), one acting as client and the 
other one as host of the mirage-static and mirage-www unikernels. (The spurios 
trailing bytes are also present on last client Syn-ack)

Thomas, Dave, Balraj-- should Mirage be ACKing these spurious bytes
(one assumes not even if they're included)?  But any ideas why they're
included at all -- is this a Xen issue?!

--
Richard Mortier
richard.mortier@xxxxxxxxxxxx

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



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


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