First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

SYN followed by PSH ACK with incorrect ACK sequence number

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 :)

aspyct's avatar
3
aspyct
asked 2018-11-08 18:27:44 +0000, updated 2018-11-08 18:41:47 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

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

Spooky's avatar
191
Spooky
answered 2018-11-09 03:29:17 +0000
edit flag offensive 0 remove flag delete link
more

Comments

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

aspyct's avatar aspyct (2018-11-09 09:22:56 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer