Wireshark-users: [Wireshark-users] [semi-OT] request second opinion on possible bugs in OS TCP wi
List, I am looking for a second opinion on what I believe is one or
more bugs in inplementation of TCP receive and send window, or
selective acknowledgement. On a Nokia S60 device for sure, and
possibly on an unidentified server side OS. I don't know where else to
find packet gurus. If after reading this and you're interested in
helping, please e-mail me individually and I'll reply with the PCAP.
Problem: troubleshooting web surfing failures to some web pages from a
Nokia N86 S60 phone. The phone is behind a wifi router.
Collection: There is a network tap inline between the wifi router and
the cable modem. The traffic collected is *already off* the wifi LAN
segment and is about to enter/exit the Internet. The test is to the
web site http://isc.sans.org
Diagnostic: Run the following tshark command to output the necessary fields:
tshark -r sack_fail.pcap -T fields -e frame.number -e ip.src -e
tcp.srcport -e ip.dst -e tcp.dstport -e tcp.flags -e tcp.seq -e
tcp.ack -e tcp.options.sack_le -e tcp.options.sack_re -e tcp.len -e
frame.time
This is my assessment of what is going on:
Frame 1-3: three way handshake, normal
Frame 4: client sends HTTP GET request, normal
Frame 5: server ACK frame 4, normal
Frame 6: server sends payload segment 1 (PS1), normal
Frame 7: server sends PS2, normal
Frame 8: client ACK PS2, normal
For some reason, frame 8 is not received or processed by the server
(this is a mystery, but not discussed here.)
Frame 9: server resends PS1, normal
***Frame 10: client receives frame 9, a duplicate of frame 6. Client
ACK frame 7, but sends a SACK with the segment from frame 6.
This is clearly incorrect behavior, ref the SACK RFC, RFC2018. The
client is treating frame 9 as an out of order packet and jumping into
SACK mode, but frame 9 is merely a duplicate or retransmit. Frame 9
falls outside the client's receive window (updated after frame 7) and
should discard it, but doesn't. My theory is that the client (Symbian
OS TCP stack) is not doing a bounds check on its TCP receive window.
Frame 11: The server TCP stack has received an invalid SACK and is now
confused. It retransmits PS1. This is semantically incorrect because
the client actually indicates it has received PS1.
Frame 12: client retransmits frame 10
Frame 13: server retransmits PS1
Frame 14: client retransmits frame 10
Frame 15: server retransmits PS1
Frame 16: client retransmits frame 10
Frame 17: server sends PS3, normal
Somehow, this "breaks the spell", for the moment.
Frame 18: server sends PS4, normal
Frame 19: server sends PS5, normal
Frame 20: server sends PS6, normal
Frame 21: server sends PS7, normal
Frame 22: server sends PS8, normal
Frame 23: server sends PS9, normal
Frame 24: server sends PS10, normal
Frame 25: server sends PS12 with FIN, received out of order
Frame 26: server sends PS11, received out of order
Frame 27: client ACK PS4, normal
Frame 28: client ACK PS6, normal
Frame 29: client ACK PS8, normal
Frame 30: client ACK PS10, normal
Frame 31: client ACK PS10, but sends a SACK saying it has received PS12, normal
Frame 32: client ACK PS12, normal
Frame 33: client sends FIN/ACK, acknowledging server's FIN from frame 25, normal
At this point, the client is expecting an ACK to its own FIN.
Frame 34: for some reason, the client does not receive an ACK to its
FIN, so two seconds later it retransmits a FIN/ACK, normal
***Frame 35: server resends PS1, 2.7 seconds after the client sends
the first FIN in frame 33
Why oh why does the server (unknown OS) do this? the SACK storm from
earlier seemed to have broken, the client has acknowledged all the
later payload segments, the server has sent its FIN, and the client
has sent its FIN (twice.) PS1 should be out of the server's TCP send
window anyway.
Could the server TCP stack have a bug in its send window implementation?
As we saw from frame 10, the client misbehaves with duplicate packets.
Another SACK storm now commences.
I'd appreciate additional pairs of eyes on this packet capture. Thanks.
Alan
