Ask Your Question
0

SYN followed by PSH ACK with incorrect ACK sequence number

asked 2018-11-08 18:27:44 +0000

aspyct gravatar image

updated 2018-11-08 18:41:47 +0000

I'm investigating network issues at our office. I'm not on the network team and have no details on the network topology, but here's a trace of what happens on my machine.

https://www.dropbox.com/s/mbhnd4e34ft...

You're looking at a curl HTTP request made from my workstation to my own website. The website was working fine at the time the capture was made. Just before that, two other HTTP requests went through fine, but this one eventually timed out. I had a similar behavior on other websites.

Note that wireshark is indicating "TCP ACKed unseen segment", but I'm pretty confident I didn't miss packets: the 2 http requests made just before that were complete, and there wasn't much network traffic except for some broadcast.

I'm seeing two things wrong here:

  1. the initial SYN gets a PSH/ACK response
  2. the ACK sequence number on the first response is random

From my understanding, the first response from the server should be a SYN/ACK with a sequence number of 1. I've never seen a SYN, PSH/ACK, ACK sequence (although, admittedly, my TCP knowledge is a bit rusty).

So here come the questions:

  1. is there a case where a PSH/ACK would be a legit response to a SYN, and what about that ACK sequence number?
  2. if it is indeed an error, do you know of any network equipment that would be likely to cause that error?

Thanks for your time :)

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2018-11-09 03:29:17 +0000

Hi,

There should always be a 3-way handshake when starting a new TCP connection.

(Corner cases exist but are very rare. Ex. RFC 7413 "TCP Fast Open")

The PSH/ACK doesn't make sense either even if it uses the same ports server 80 to your 61738.

You may be facing an issue with a device doing NAT where there are not enough resources (port exhaustion) to NAT all connections.

You may also be facing an issue with a device like a load-balancer or firewall that doesn't properly or promptly clear its state table.

I suggest you check that your curl client is using a "fresh" (new) TCP source port when connecting to your web server.

Good hunting.

JFD

edit flag offensive delete link more

Comments

Thanks, I'll try and discuss these possibilities with the network team!

aspyct gravatar imageaspyct ( 2018-11-09 09:22:56 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-11-08 18:27:44 +0000

Seen: 2,380 times

Last updated: Nov 09 '18