1

Consider this short Wireshark packet capture on Windows Server 2016:

Overlapping TCP packets

Frame-1

TCP Window Size of client (192.168.201.5) is 1504 bytes.

Frame-5

TCP Server responded back with a packet (length 1083).

TCP Payload: 1029 bytes
TCP Seq No: 1

Frame-6

Without waiting for acknowledgment of previous packet, server sent another packet (length 1414).

TCP Payload: 1360
TCP Seq No: 145

Summary

So in order to maximise the payload transfer:

  • Server sent 1..1029 bytes of data in first packet.
  • server sent 145..1504 bytes of data in second packet.
  • Effectively both packets contain 145..1029 bytes.

Question

This server is talking to small devices whose TCP stack is not powerful enough to assemble the packets containing overlapping data. So the session fails (TCP reset in Frame-12).

Is there any way to configure Windows so that it sends simpler (non-overlapping) packets?

EDIT You can download the pcap file for full details.

EDIT-2:

Download pcap file of full session This session can be seen by applying a filter tcp.port == 50002 and ip.addr == 192.168.201.5

8
  • Could you please provide the full pcap and not just an image showing a few details of it? The image alone does not provide sufficient information to see what's going on. – Steffen Ullrich Jun 3 '20 at 5:52
  • @SteffenUllrich Sure. Attached now. – Hemant Jun 3 '20 at 6:06
  • Your original PCAP file starts from frame 244, while the attached PCAP starts from frame #1. What is the difference between the PCAP files? – Tero Kilkanen Jun 3 '20 at 6:53
  • @TeroKilkanen Since apologies for confusion. Actually the original screenshot was of full session. In the pcap file, I exported only one session which changes the frame numbers. I have fixed the screenshot to match with pcap fie now. – Hemant Jun 3 '20 at 7:02
  • The full session has important details to answer the question properly. My answer below is an educated guess what might be happening, but without the full PCAP I don't know if that is a valid guess. – Tero Kilkanen Jun 3 '20 at 7:04
2

To me, it seems there are packets from two different TCP sessions in the dump. The sessions just seem to have same port numbers, which causes the RST behavior.

Frames 1-5 and 7-8 belong to the same session, while frame 6 is for some other session.

Does the client device use a random TCP port as the source port when opening connections?

3
  • These devices use GPRS communication. Communication provider does some sort of address and port translation. But I do see the same port being reused after some time (about a minute). Not sure if this can cause any issue. – Hemant Jun 3 '20 at 7:22
  • As evident from the full pcap file, there are no other session for same address+port. This packet is definitely part of the same session. Please can you suggest anything? – Hemant Jun 3 '20 at 11:17
  • 1
    Just a guess, it could be a bug in Windows TCP stack with small TCP window / segment sizes. Window size is 1504 bytes here, and MSS is 1360 bytes. 1504 - 1360 = 144, which is the SEQ difference between frames 5 and 6. Maybe Windows TCP stack works incorrectly when TCP window is less than 2xMSS. – Tero Kilkanen Jun 3 '20 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.