[lwip-devel] [bug #34435] fast retransmits can result in unordered unsent list

[Kieran Mansley]

Follow-up Comment #3, bug #34435 (project lwip):

I think I can see the potential problem.  It all hinges on the behaviour of
TCP_SEQ_LT.

In tcp_rexmit() we take the first segment on the unacked list and return it to
the unsent list.  We attempt to keep the unsent list ordered by comparing
sequence numbers using TCP_SEQ_LT.  If this was just a straight comparison of
sequence numbers, and the sequence number had recently wrapped, it could put
the segment we are moving (with sequence number 0xFFFFFF00) at the tail of the
unsent list rather than at the head of the unsent list.

However, the implementation of TCP_SEQ_LT that we currently have will I think
give the right answer:

#define TCP_SEQ_LT(a,b) ((s32_t)((a)-(b)) < 0)

e.g. comparing a=0x00000300 to b=0xFFFFFF00 will give:
(a)-(b) = 1024 and so cast to s32_t this is > 0 and TCP_SEQ_LT returns false. 
Because it is false the while loop in tcp_rexmit will terminate and it will
put 0xFFFFFF00 segment at the head of unsent, *not* at the tail.

I.e. I agree it is fine.

One way that it could fail is if the reporter's ntohl() implementation wasn't
returning unsigned values.  I'm not sure if our TCP_SEQ_LT macro would then
give the right answer.  Perhaps we should be casting (a) and (b) to unsigned?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?34435>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/