On 7 June 2015 at 16:11, Carlos Oviedo <[email protected]> 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 [email protected] _______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
