Wireshark mailing list archives
[semi-OT] request second opinion on possible bugs in OS TCP window and SACK implementation
From: Alan Tu <8libra () gmail com>
Date: Sun, 16 Jan 2011 16:00:29 +0000
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 ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- [semi-OT] request second opinion on possible bugs in OS TCP window and SACK implementation Alan Tu (Jan 16)
- Re: [semi-OT] request second opinion on possible bugs in OS TCP window and SACK implementation Sake Blok (Jan 16)
- Re: [semi-OT] request second opinion on possible bugs in OS TCP window and SACK implementation Sake Blok (Jan 16)