Revision history [back]

The second TCP connection ending around frame 871 should be considered complete. If you see FIN packets on both sides the connection has ended from the standpoint of either side.

You have a client-server pair that is re-using the TCP ports (specifically the client is re-using the source port). This too should not be a problem because of the long delay of 15 minutes between the last FIN sequence and the new SYN sequence.

Looking at the SYN packets of the first two successful connection sessions and comparing against the SYNs that lead to RST responses, there seems to be no significant difference that would cause them to invoke RSTs. This means, the client is probably not responsible for these RSTs.

As recorded on the server, it is returning RSTs to inbound SYNs from the linux client. Based on previous observations here, it is more probable that the server is responsible for the RSTs. The cause should not be external (other TCP communications/ packets) because we have a server side capture.

While, a "TCP connection re-use" issue does not appear to be a likely reason for this behavior, can you (nevertheless) try making the client rotate source ports from a bunch of port numbers (say 3 or 10)? If you get a reproduction with that change it will eliminate the re-use related issues completely.

As an aside, have you investigated the reason for the re-transmits in the first two TCP sessions?

One more aspect to check is the other communications that Windows server is handling. If there are too many connections on going that could load its TCP stack. But, a consistent reproduction with failures starting at the 3rd connection on 15 minute intervals does not seem to suggest a "3rd party" interference.

The second TCP connection ending around frame 871 should be considered complete. If you see FIN packets on both sides the connection has ended from the standpoint of either side.

Correction1: I don't know why I thought the source port is not moving. My bad.
You have a client-server pair that is re-using the TCP ports (specifically the client is re-using the source port). This too should not be a problem because of the long delay of 15 minutes between the last FIN sequence and the new SYN sequence.

Looking at the SYN packets of the first two successful connection sessions and comparing against the SYNs that lead to RST responses, there seems to be no significant difference that would cause them to invoke RSTs. This means, the client is probably not responsible for these RSTs.

As recorded on the server, it is returning RSTs to inbound SYNs from the linux client. Based on previous observations here, it is more probable that the server is responsible for the RSTs. The cause should not be external (other TCP communications/ packets) because we have a server side capture.

Correction1: re-use is out of question because source port is moving.
While, a "TCP connection re-use" issue does not appear to be a likely reason for this behavior, can you (nevertheless) try making the client rotate source ports from a bunch of port numbers (say 3 or 10)? If you get a reproduction with that change it will eliminate the re-use related issues completely. completely.

As an aside, have you investigated the reason for the re-transmits in the first two TCP sessions?
Update1: There are also lost frames in the communication (example: between frames 757 and 759 a bunch of client sourced frames are missing from the capture).

One more aspect to check is the other communications that Windows server is handling. If there are too many connections on going that could load its TCP stack. But, a consistent reproduction with failures starting at the 3rd connection on 15 minute intervals does not seem to suggest a "3rd party" interference.