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

[Bernard Shyu]

Hi,

>
> > 3. tcp_output.c::tcp_enqueue()
> >    It seems to be wrong in the TCP header offset calculation.
> >      TCPH_OFFSET_SET(seg->tcphdr, 5 << 4)
> >    should be changed
> >      TCPH_OFFSET_SET(seg->tcphdr, 5 * 4)
> >    or
> >      TCPH_OFFSET_SET(seg->tcphdr, 5 << 2)
> >    Obviously other places for the offset calculation are likewise
> > incorrect.
>
> No, the lwIP code is correct, but it looks slightly confusing. The << 4 is
> made because the offset field is in the high four bits of the octet
> containing the field. This is how that part of the header looks like (from
> RFC793):
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Data |           |U|A|P|R|S|F|                               |
>    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
>    |       |           |G|K|H|T|N|N|                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 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 ?

> > 4. tcp.c::tcp_slowtmr()
> >    It seems to me quite obscure about::
> >      /* Move all other unacked segments to the unsent queue. */
> >
> >    When retransmission time-out occurs, I believe that only the 1st
unacked
> > segment need to be resent. It is quite possible that only the 1st
unacked
> > segment is missing, while the ACKs for all other unacked segments are
still
> > wandering in the network and will arrive sooner or later.
> >
> >    On the other hand, moving the unacked segments to unsent queue, isn't
it
> > equivalent to shifting left the TCP Window ??
>
> The reason for doing this is when one segment is lost, chances are that
others
> following it were lost as well. If the others where received properly, the
> receiver will send an ACK that acknowledges those segments. lwIP will
> deallocate segments from both the unacked and the unsent queues when an
ACK
> is received.
>

Since I am a newbie not only in this discussion list, but also in the field
of TCP/IP. I only started my TCP/IP study since last Aug till last week,
with Richard Steven's TCP/IP Illustrated Vol 1&2. I started your code study
only since 3rd May. Let alone knowing the RFC stuffs. Therefore, my
assertion might be wrong, and correct them if possible :)

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.

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 ?

Regards,
Bernard





==========================================================
 PC home ¹q¤l«H½c¡A¥Ó½Ð½Ð¦Ü: http://www.pchome.com.tw
 PC home Online ºô¸ô®a®x¡G·|address@hidden
==========================================================
[This message was sent through the lwip discussion list.]