lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] at ZeroWindowProbe the response is not ZeroWindowProbeA


From: Kieran Mansley
Subject: Re: [lwip-users] at ZeroWindowProbe the response is not ZeroWindowProbeAck
Date: Tue, 17 May 2011 15:23:35 +0100

On Tue, 2011-05-17 at 16:12 +0200, Thomas Richter (TCD - DE/Dresden)
wrote:
> The next sequence by the sender is a TCP_ZeroWindowProbe sequence
> (some
> infos to TCP Analyze Sequence Numbers with Wireshark:
> http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers). But lwIP
> responses not with a sequence TCP_ZeroWindowProbeAck, it sends a new
> TCP_ZeroWindow sequence.

Do you have definitions for things like TCP_ZeroWindowProbeAck?  As far
as I'm aware the form that a zero window probe should take is not
defined; it can be anything that will result in an ACK being sent by the
other end, and I didn't think there was a particular form that the ACK
to a zero window probe had to take.

> With another device with another TCP/IP stack the following I can
> observe:
> time 1:    192.168.1.1 ==> 192.168.1.100
> seq.no.:        6150
> ack.no.:        2532
> next seq.no.:   6151
> 
> time 2:    192.168.1.1 <== 192.168.1.100
> seq.no.:                    2532           (is the expected sequence)
> ack.no.:                    6150           (is the expected ACK)
> 
> This will be continued until the receiver (192.168.1.100) can handle
> new
> data.
> 
> With lwIP the following I can observe:
> time 1:    192.168.1.1 ==> 192.168.1.100
> seq.no.:         8351
> ack.no.:        17202
> next seq.no.:    8352
> 
> time 2:    192.168.1.1 <== 192.168.1.100
> seq.no.:                    17202          (is the expected sequence)
> ack.no.:                     8352          (is not the ACK to 8351)
> 
> The increase of acknowledge number by 1 is curios.

The zero window probe in your case has 1 byte of payload.  lwIP is
accepting and acknowledging that byte.  As far as I know this is legal. 

> Why lwIP reacts different?

Different implementations of a specification will have different
behaviours where that behaviour is not defined by the specification.

> What can I do that the acknowledge number not increases?

Change the implementation of lwIP.  Out of interest, why do you care
about this?  The values being acknowledged should not be of interest (or
even visible) to the application using lwIP.

Kieran




reply via email to

[Prev in Thread] Current Thread [Next in Thread]