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 edited 01 Mar '16, 03:07 |
One Answer:
The trace you uploaded contains only TCP_KeepAlive packets with a single garbage byte. answered 01 Mar '16, 04:11  mrEEde |
That's one of the dangers of relative sequence numbers - it can fool you in some situations :-)
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!