This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RST after SYN-ACK

0

Hi, i´m facing a strange behavior for a simple telnet connection test, my station send the SYN packet, that go to a server, receive the [SYN, ACK], and just then send a RST. I believe the SYN,ACK packet its malformed, but i couldnt identify what its wrong. Can anyone help me.

Here is the packet capture, pcap format: https://docs.google.com/file/d/0B9Co4kddbAUWa0lCRlJ2WmJGS2M/edit?usp=sharing

Thanks a lot!

asked 20 Aug '13, 15:58

fabioalkas's gravatar image

fabioalkas
11112
accept rate: 0%


2 Answers:

0

The acknowledgment numbers in the SYN/ACK packets are not correct for the SYN packets that they are acknowledging.

For example, the (absolute) sequence number in frame 1 is 3839424768. The acknowledgment number in the SYN/ACK packet in frame 3 should be 3839424769, but instead frame 3 has an acknowledgment number of 14744888. Because of this, the SYN/ACK packet from 10.223.100.100 does not correspond to a SYN packet sent by 10.0.5.45, so 10.0.5.45 sends a RST.

If the server is under your control, try capturing on both the client and server simultaneously. Either:

  1. The sequence number in the SYN packet from the client is being changed by an interconnecting device, and the server is responding to this changed sequence number, or
  2. The acknowledgment number in the SYN/ACK packet from the server is being changed by an interconnecting device, or
  3. Something has gone wrong with the server's TCP/IP stack and it is responding with the wrong acknowledgment number.

You might check the configuration of your Sonicwall firewall to see if it is mangling sequence and/or acknowledgment numbers. If you can, try capturing the same communication on both sides of the firewall simultaneously so that you can see what, if anything, is changed as packets pass through the firewall.

answered 20 Aug '13, 21:40

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

0

I have seen an issue which looks like multi-pathing problems on an Amazon EC2 VM with a 3.4.x kernel and a proper network config ... it's not always the firewall :) The bug is that the kernel sends the wrong TCP sequence number to the client in the SYN_ACK packet.

answered 19 Sep '13, 09:47

Dave%20Crooke's gravatar image

Dave Crooke
1
accept rate: 0%