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

[Adam Dunkels]

Hi!

On Wednesday 08 May 2002 04.49, Bernard Shyu wrote:
> I'm newbie to lwIP open-source community and just started to study the
> source code. Belows are some BUG -- I believe so.
>
>
> 1. api_lib.c::netbuf_copy_partial()
>    Obviously the for loop is to find the first pbuf containing the offset
> databyte and then copy from then on. But the offset value should be reset
> to ZERO since that pbuf is located. The current invokation from
> netbuf_copy() doesn't make problem, simply because offset is supplied with
> 0.

Yes, this was actually fixed yesterday by a tip from Jani Manoses. 

> 2. tcpip.c::tcpip_apimsg()
>      memp_free(MEMP_TCPIP_MSG, apimsg)
>    should be changed to
>      memp_free(MEMP_API_MSG, apimsg)

Ok, fixed! Thanks!

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

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

Thanks for your bugfixes!

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam

[This message was sent through the lwip discussion list.]