Retransmission vs keep-alive - bad seq number

Question

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.

link:capture

Answer 1

0

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

answered 27 Oct '16, 07:59

Christian_R
1.8k●2●6●25
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 ♦

@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
octet.

(27 Oct '16, 22:36) Christian_R

showing 5 of 7 show 2 more comments

Answer 2

If the SEQ and ACK numbers were not anonymized, then I would say that both TCP implementations have issues.

10.1.2.3 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 8.7.6.5 to retransmit the SYN/ACK if the ACK got lost.

8.7.6.5 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?

Answer 3

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.