This is our old Q&A Site. Please post any new questions and answers at

Pkt #3 is lost in transit. Packet 4 is a retransmit (based on timing and changed timing when rto is changed). Shown as keep-alive due to incorrect Seq number in pkt 4.

So two issues, why is Seq incorrect in #4 and how can WireShark figure out it is a retransmit vs keep-alive.


asked 27 Oct '16, 07:41

devilbob's gravatar image

accept rate: 0%

Are the TCP CRC errors and undersized packets also present in the original capture (before sanitizing it)? If so, the capture quality isn't really that good...

(27 Oct '16, 10:39) Jasper ♦♦

No, the CRC errors are a function of the sanitizing. Not sure why you are saying the packets are undersized. They all look good to me.

(27 Oct '16, 12:54) devilbob

Jasper has meant, that the first packet has a size of 74 Byte. The second is 58 Byte. But the other packets are only 54 Byte long. That can normally not be. If we trace on a host the local packets might be under 64 byte. But the incomming packets are normally never under 64 byte.

(27 Oct '16, 13:15) Christian_R

Could you provide the output of :

tshark -r retran_anon.pcapng -otcp.relative_sequence_numbers:FALSE -T fields -e frame.number -e frame.len -e tcp.seq -e tcp.ack -e tcp.len -e tcp.window_size

It would show if the sanitizing might have messed with some of the TCP headers...

(27 Oct '16, 15:38) SYN-bit ♦♦

@devilbob thanks, I think I need to adjust the Tracewrangler default setting a bit.

(27 Oct '16, 15:53) Jasper ♦♦

The RFC 1122 definition of KEEP-ALIVE is next SEQ -1:

permanent link

answered 27 Oct '16, 07:59

Christian_R's gravatar image

accept rate: 16%

edited 27 Oct '16, 08:09

I wonder if the client is upset because the server's SYN, ACK response has a window scale of 0?

(27 Oct '16, 08:01) grahamb ♦

@grahamb: Not only the window scaling is not advertised but the entire window is zero. Yeah I think that is the reason why the session looks so strange. At the beginning. In Packet #5 the system sets the Window to 4096 Byte. But the client never tells the server what he wants from the server. At the end the 8.x.x.x closes the session.

(27 Oct '16, 08:12) Christian_R

@Christian_R, I meant window size.

(27 Oct '16, 08:16) grahamb ♦
(27 Oct '16, 08:19) Christian_R

However keep-alives shouldn't happen till after two hours of idle.

Part of the issue is the window size. All connections with this server have the window size set to 0 in the syn/ack. Normally when it sees the 3rd packet it sends a window size update with ACK=1 and SEQ=1. When the ACK isn't received, then the retransmission is seen as the ACK but what would be the window update has ack=0 and we seem to ignore it except to resend a dup ACK which they ignore.

I have set the rto to 10 seconds and the other end does not resend the syn/ack in that time before we send the retransmission. Now trying with 30 seconds.

(27 Oct '16, 12:53) devilbob
However keep-alives shouldn't happen till after two hours of idle

That´s not the whole true. 2 hours is the default for keep alives, but the time must be configurable. So I don´t know what time your system has configured.

BTW: About what OS do we speak?

(27 Oct '16, 13:10) Christian_R

Maybe the following situation has happened here. But the text is from the year 1989. So I am really not sure:

Unfortunately, some misbehaved TCP implementations fail
to respond to a segment with SEG.SEQ = SND.NXT-1 unless
the segment contains data.  Alternatively, an
implementation could determine whether a peer responded
correctly to keep-alive packets with no garbage data
(27 Oct '16, 22:36) Christian_R
showing 5 of 7 show 2 more comments

If the SEQ and ACK numbers were not anonymized, then I would say that both TCP implementations have issues. should not send frame #4, as there is no data to retransmit. The phantom byte in the SYN has been acknowledged in frame #2 and therefor it is the duty of to retransmit the SYN/ACK if the ACK got lost. however should not use an ACK of 0 in frame #5 as it already acknowledged the phantom byte of the SYN in frame #2, therefor the ACK should be 1 (even though it should not send an ACK in the first place as there was no data received).

Are both systems using a custom TCP/IP implementation?

permanent link

answered 27 Oct '16, 15:48

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

No, is using vanilla RHEL 6.8. Not sure what the other end is running. I do know they have an F5 in the mix but they have been unable to provide captures. Not really sure why not but they claim not to be able to. I did at one point get a capture from their firewall, one direction used public address and the other direction used private addresses. Looked like we were seeing one direction on pre-NAT and the other post-NAT.

(31 Oct '16, 05:56) devilbob

I now understand this capture. The other end is misbehaving, but the "keep-alives" shown in wireshark are in this case zero-window probes. I didn't realize that zero-window probes use the same timer as rto. So the syn/ack said zero window and we want to start this conversation so we probe.

I'm good with this now I just have to get the capture from the other end to confirm.

Thanks for all the input.

permanent link

answered 01 Nov '16, 07:25

devilbob's gravatar image

accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 27 Oct '16, 07:41

question was seen: 2,502 times

last updated: 01 Nov '16, 07:25

p​o​w​e​r​e​d by O​S​Q​A