lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Re: bug fix


From: Winformatik Info
Subject: Re: [lwip-users] Re: bug fix
Date: Mon, 27 Sep 2004 10:45:32 +0200
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

We have seen the same problem with the TCP_SEQ_BETWEEN macro in tcp_in.c (at line 822), but have not tracked down the problem yet. The processor is a S3C44B0X from Samsung in little endian and thumb mode. BTW: We use the compiler from the ADS 1.2 and/or SDT 2.50 develpoment environment.

Regards
Roland


Bill Knight schrieb:

I just finished a port from lwIP-0.7.2 to the current code in CVS.
The processor is an LPC2292 with a CS8900 ethernet chip.  The LPC is
an ARM7TDMI which operates in LITTLE_ENDIAN mode.  The problem shows
up for me when using Adam's minimal http server.  I have isolated it
to the TCP_SEQ_BETWEEN in tcp_in.c at line 822.  When I use the
previous macros, the code serves pages just fine.  When I use the new
macro, it does not.  The code fragment the works is:

   while (pcb->unsent != NULL &&
          TCP_SEQ_LEQ(ntohl(pcb->unsent->tcphdr->seqno) + TCP_TCPLEN(pcb->unsent), 
ackno) &&
          TCP_SEQ_LEQ(ackno, pcb->snd_max)
          /*TCP_SEQ_BETWEEN(ackno, ntohl(pcb->unsent->tcphdr->seqno) + 
TCP_TCPLEN(pcb->unsent), pcb->snd_max)*/

So far I have been unable to determine why in this instance the macro
does not work.  Maybe something to do with LITTLE_ENDIAN.  Maybe
another set of eyes can spot it.

Regards
-Bill Knight
theARMPatch

PS - the compiler is arm-elf-gcc version 3.4.0


On 12 Sep 2004 17:03:22 +0100, K.J. Mansley wrote:

On Fri, 2004-09-10 at 17:14, Brett Jones wrote:
The problem is that tcp protocol uses a unsigned 32 bit value for a
sequence number and acknowlegement. As each packet is sent the
sequence number is increased by the amount of data that is sent and
normal comparisons work fine until the sequence number becomes more
than a 32 bit value will hold ( 4,294,967,295 ) the sequence number
rolls over and even though you have added to the sequence number the
sequence number becomes less than it was before. with a signed number
the problem is even worse because it rolls over at 2147483647. when
you add 2 to this number it becomes -1
then lwip comparisons dont work correctly and does not think that its
packets have been acknowleged (out of window) and the que becomes
full. to fix this you check for rollover and if a rollover has occured
you reverse the comparison logic :)
This fix has made it possible for me to transfer large amounts of data
whereas a tcp connection was shutdown every 2 or so gigabytes of data
transfered before.

OK.  I've had a look at how linux does things, and its macros are the
same as ares (and the comment says it copes with wrap-around) except
they had a TCP_SEQ_BETWEEN macro to determine if b <= a <= c, and it's
conceivable that compound use of the simpler "TCP_SEQ_LTEQ" macro to
achieve the same effect doesn't work for wrap-around, but I'm not sure.

To be on the safe side I've added this "BETWEEN" macro to lwip, and
replaced any logically equivalent statements with this.  I've left the
old statements in place just to be clear what the real intention is, in
case I've translated them wrongly.

Would be grateful for another pair of eyes to look these changes over
and see if this:
(a) fixes the problem
(b) makes things worse

Any volunteers?

Thanks!

Kieran



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users






_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users






reply via email to

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