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

TCP ACKed unseen segment - wireshark bug?

1

This is a screenshot of a complete 'echo' conversation between a PC and an embedded device with a small 64 byte window size. It looks like wireshark loses track of the conversation when the embedded device ACKs the zero window probe and opens its window on #136. Is this the same bug as reported here?

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8404

screenshot

Larger image link

asked 17 May '13, 10:03

Andy%20Brown's gravatar image

Andy Brown
16113
accept rate: 0%

edited 17 May '13, 10:05


2 Answers:

1

I'm not sure if it is the exact same problem, but in your case the TCP expert seems to get into trouble when seeing a window probe that doesn't send the last already ACKed byte but the next byte to come. The TCP expert calls packet 135 a ZeroWindowProbe because

  1. the sequence number is the next expected one
  2. the window in the other direction is zero
  3. and the segment holds just 1 byte

The conditions for a ZeroWindowProbeACK are:

  1. the previous ACK is repeated
  2. the last segment in the other direction was a ZeroWindowProbe

Obviously, the first condition is not met here, because the ACK no. is 66, not 65. Instead, now the "ACKed lost segment" diagnostic code seems to kick in, and marking the previous segment lost, which is clearly not true. I guess the TCP expert code needs to be changed to consider ZeroWindowProbe packets like the one in your trace and not diagnose a "lost segment". So you could attach your problem to the bug you mention, because it is probably caused by a similar part of the TCP expert code.

answered 17 May '13, 13:06

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

0

frame 136 : this is a ack of the tcpzerowindowprobe segment ( frame 135 ) but as ack=66 means that the byte from the probe segment is consumed by TCP_192.168.1.3 ( we also see that window=63 and 63=64-1 )

for me , I think the correct name for frame 136 is TCP_ZeroWindowProbeAck and not TCP_ACKed unseen segment. May be a bug.

I have the same behaviour with the following trace alt text

frame 4 to 10, 10.0.3.68 get 4 segments of 128 bytes, then last received segment is acked with a window of 0 ( frame 11 ). As the window of 10.0.3.68 is closed , 10.0.3.70 send window probe segments wich are allway acked from 10.0.2.68 : frame 13 to 19. we see also that the probe byte is not consumed because seq equal ack for each probing EXCEPT the last probe : frame22 when 10.0.3.68 get frame 22, it TCP application has consumed data and the window can be re-opened. So the frame 22 ( window probe ) is acked but the probe byte is consumed ack = seq + 1 = 108420 win different of 0

answered 29 Jan '14, 08:53

gibu's gravatar image

gibu
112
accept rate: 0%