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

TCP streams missing first 2 packets of 3-way handshake

0

I have 30+ TCP streams in a trace that all have in common that they miss the first 2 packets in the 3-way handshake and have some weird SEQ/ACK numbers going on. The trace is done on the 156.7.53.9 computer. The data being sent is either SQL queries or simply a dot "."

Here is one such stream's traffic: https://www.cloudshark.org/captures/ac136803a5cd

Questions:

-why would a large amount of TCP streams lack the first 2 packets in the handshake? I can't find any signs of packet loss elsewhere in the trace file.

-The 1st packet in this trace in reality is the 3rd packet of the TCP handshake. Why would the third packet in the handshake contain a "." ? Make sense to anyone?

-I cannot make sense of the ACKs and SEQ's going up/down all the time. Shouldn't they just keep going up as long as there is no packet loss?

Thanks, Skjalg

asked 01 Mar '16, 03:05

Skjalg's gravatar image

Skjalg
6114
accept rate: 0%

edited 01 Mar '16, 03:07


One Answer:

3

The trace you uploaded contains only TCP_KeepAlive packets with a single garbage byte.
So there have been sessions sitting idle when you started the capture.
Just the sequence and ack number being 1 doesn't make them the 3rd packet of the three-way handshake.
Regards Matthias

answered 01 Mar '16, 04:11

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

That's one of the dangers of relative sequence numbers - it can fool you in some situations :-)

(01 Mar '16, 04:59) Jasper ♦♦

The fact that ACKs/SEQs start at 0 regardless of where in the stream you start capturing allured me - makes perfect sense of course :-)

Did a little search on the garbage byte you mentioned and learned that these are in fact a part of TCP Keep Alives. Since many TCP implementations will not reliably deliver a segment containing only an ACK & no data, it is common to use a garbage octet/byte as payload in a Keep Alive. By lowering the SEQ# accordingly, the receiving end will understand it is a Keep Alive and simply reply to the sender without passing any data to the application layer (since it knows it already acknowledged the data represented by the sender's SEQ#)

I live and learn :-)

Thanks Matthias!

(01 Mar '16, 22:20) Skjalg