lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Re: [lwip] Probably some bugs


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] Probably some bugs
Date: Thu, 09 Jan 2003 02:33:52 -0000

Hi!

On Wednesday 08 May 2002 18.44, you wrote:
> > The data offset is shifted four bits left. The "5" in the "5 << 4"
>
> expression
>
> > is actually 20/4, which is the number of 32 bit words in the TCP header.
>
> Good trick, but would it be better if they could be commented in the
> code ?

Its not really a trick, but a standard mechanism to put the data into the 
right position in the octet. It used to be implemented using C bit fields but 
because that wasn't very portable, this way was chosen instead. Perhaps it 
would be more clear if it was written (20 >> 2) << 4 instead.

> When a segment is lost, how much is the chance for the subsequent ones to
> be also lost as well ? Even if they are all lost, the retransmission will
> still work on the 1st unacked one, repeatedly, with exponential back-off.
> The remaining unacked segments are still kept in the sender's buffer
> (somewhere) without resending. From my understanding of your code, leaving
> them on the unacked queue or moving into unsent queue, simply doesn't
> matter at all -- still only the 1st unacked one will be resent.

Retransmission will not be made on a per-segment basis. Rather, when the 
first segment has been retransmitted, the transmission will "start again" at 
the retransmitted segment and will continue to work as it would have been 
without the retransmission.

> On the other hand, if the subsequent unacked segments were received, but
> the response ACK is delayed for some reason so that it reached to the
> sender after the time-out retransmission, then lwIP must then realize that
> some of the UNSENT segments which were just moved from unacked queue are
> actually the ones being ACK'ed and must be deallocated as well the unacked
> queues. However, the problem is, what if a malicious (or buggy) peer which
> ACK with an actually UNSENT seq number ??  Can lwIP tell ??
>
> In BSD's version, the unsent and unacked boundary are maintained by
> PCB->snd_max, which will only slide to the RIGHT. A retransmission is
> simply an assignment of snd_nxt to snd_una. An important sanity check for
> TCP input processing of ACK is by the check of
>     snd_una < ACK <= snd_max
>
> In lwIP, moving unacked segments into unsent queue, from my understanding,
> is equivalant to shift the "snd_max" value to the LEFT. In spite it is an
> internal mechanism, the advertised window is still maintained without
> moving to the LEFT, but the sanity check will be a problem, right ?

Your perception is correct - lwIP does not do the sanity check that BSD does. 
This is only a bug, however, and not an intentional design descision. (Not a 
very large bug, but a bug nonetheless.) LwIP maintains a snd_max variable 
just like BSD does. I'll add the sanity check to the tcp_input code.

Thanks for spotting this!

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]




reply via email to

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