 | 1 | initial version |
Interesting trace with quite a few things going on.
The trace was made near or on the client (192.168.0.6), as can be seen from the delta times between the SYN and the SYN/ACK and between the SYN/ACK and the ACK of the 3-way-handshake.
The frame length of 2962 of some of the frames sent by the client confirms this (these large frames are caused by capturing on a host that does TCP segmentation offloading). Jumboframes are not in play as the MSS value in the SYN is 1460.
The first interesting bit is frame 11, there is TCP data missing, but the id.ip values is one higher that the previous frame from the server. So there seems to be something weird going on on the server side.
As the server retransmits the missing data, the TLS session is setting up fine. This can be seen by disabling dissection of frame 11 (select the frame and choose "Edit -> Ignore/Unignore packet").
Things go well for a while where client and server are exchanging data, until frame 41. This frame is not received by the server. When filtering on ip.src==192.168.0.6, you can see that the frame is being retransmitted over and over, but no ACKs are coming back from the server side. Communication to the server side seems lost.
Communication from the server to the client seems OK. The server is sending TCP KeepAlive packets every 30 seconds (filter on ip.dst==192.168.0.6)
Looking closer, you can see that frames 41 and 43 were not received by the server, while frames 42 and 44 were received. You can see that in the SACK blocks in frame 49 and 52.
Filtering again for ip.src==192.168.0.6, it shows that frame 41 and 43 were the first full-size frames sent by the client. All retransmission frames are also full-size frames. This smells like a MTU problem.
Going back to the first data packets by the server. You can see that between frame 9 and 11, 2896 TCP bytes were not seen. Which are 2 packets with TCP segments of 1448 bytes (MSS=1460, but there are 12 bytes of TCP options, leaving 1448 bytes of data).
Now it makes sense that the server retransmitted the data and that the TCP segment sizes are now smaller. There was a host in the path between the server and the client that could not forward the frame because of a lower MTU size (usually caused by tunnelling). The new TCP segment length is 1408, which corresponds to an MSS of 1420 and an MTU of 1460 (instead of 1500). I assume it sent an ICMP type 3 code 4 message (Fragmentation needed, but DF bit set) to the server, which triggered the server to send smaller TCP segments.
The client either did not receive the ICMP type 3 code 4 messages (a lot of firewalls just block any ICMP packets, instead of only some of them) and therefor never switched to sending smaller TCP segments.
First thing I would check is whether the client did indeed not receive the ICMP packets. It would be better to capture the packets on a TAP or a SPAN port, than on the client itself, as you will see exactly what was on the network (remember the TCP segmentation offloading).
If the client did not receive them, check the firewalls in between the client and the Internet. If the client did receive them, send a bug report to the manufactory of the client (Xerox, as seen in the mac-address)?
Quick workaround could be to lower the MTU size on the client to 1460 instead of 1500 (if possible), but that does not solve the real issue, just avoids it.
I look forward to hear any more info on how this problem might have started and how you end up solving it.
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
