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

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

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?

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