The client sends 4 SYNs and receives RST,ACK for every one of them. Every time the relative sequence number of RST,ACK is different. Why is that so? I - SYN seq=0; RST,ACK seq=1, ack=1 For the first SYN, RST,ACK has seq=1. What has changed for the following RSTs? asked 12 Oct '11, 02:59  brklp edited 26 Feb '12, 21:24  cmaynard ♦♦ |
One Answer:
I think looking at the absolute sequence numbers might make more sense here. What is happening is that the client sends the SYN with a random sequence number and wireshark records it to be able to calculate relative sequence numbers. Then the first RST willdo the same for the opposite flow. Then when the second SYN comes in, it has the same sequence number, so Wireshark sees is as the same session. Since the server did not create a TCP control block, it has no knowledge of the sequence number it previously used and so it chosen a new random sequence number. Wireshark still thinks the numbers should start from the sequence number of the first reset and will calculate the difference. This is the corner case when no session really existed and the client does not honor the teardown of the session (which was requested by the RST). Can you post the absolute sequence numbers to verify this? Cause if the client did start a new TCP session (different seq number in each SYN), then there is something not working quite right in the TCP dissector IMHO. answered 12 Oct '11, 03:31  SYN-bit ♦♦ |
Thnx for the quick reply!
Here are the absolute numbers:
SYN seq=505a312e RST seq=00000000, ack=505a312f
SYN seq=505a312e RST seq=dcd254ee, ack=505a312f
SYN seq=505a312e RST seq=1adc11a1, ack=505a312f
SYN seq=505a312e RST seq=1d2cb23f, ack=505a312f
The fifth time the client sends SYN seq=505a312e and the server responds with SYN,ACK seq=96d277of(relative 2530375440), ack=505a312f (relative 1), the client responds with appropriate ack and the session establishment is successful.