RE: [lwip-users] Re: bug fix

[Edward Kerekes]

Regarding the request for another set of eyes to look over the changes, I just 
reviewed (desk check only) the TCP_SEQ_BETWEEN
changes in tcp_in V1.50.

 Line 1130 macro parameter 2 seems to be off by 1:

                /*if (TCP_SEQ_LT(prev->tcphdr->seqno, seqno) &&
                  TCP_SEQ_LT(seqno, next->tcphdr->seqno)) {*/
                if(TCP_SEQ_BETWEEN(seqno, prev->tcphdr->seqno, 
next->tcphdr->seqno-1)){

I believe it should be:

                /*if (TCP_SEQ_LT(prev->tcphdr->seqno, seqno) &&
                  TCP_SEQ_LT(seqno, next->tcphdr->seqno)) {*/
                if(TCP_SEQ_BETWEEN(seqno, prev->tcphdr->seqno+1, 
next->tcphdr->seqno-1)){

A similar translation was made, I think correctly, on Line 930.
Hope this helps...
Ed Kerekes



-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of K.J. Mansley
Sent: Sunday, September 12, 2004 12:03 PM
To: address@hidden
Subject: [lwip-users] Re: bug fix

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



__________________________________________________________
This message was scanned by GatewayDefender
12:03:57 PM ET - 9/12/2004