[lwip-users] Re: bug fix

[K.J. Mansley]

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