wrap bug found

Hello,

Finally found that sequence number wrap bug I was worried about few weeks
ago. It is not a race as I suspected, but a logical bug.
description:

I will describe what happens using general (non-sync source specific) packet
insertion and extraction interface, as it is easier to explain.
suppose recvFirst=0xFFF0 and recvLast=0xFFFF. packets 0,1,2,3,4 are arriving
to the ccRTP stack and will be inserted correctly to the linked list.
however, recvLast is not updated to 0x0,0x1,0x2,0x3 and then to 0x4 (packets
0x0 is condidered to be "oldest packet", and packet 0x1 through 0x4 are
"unordered packet"). Also, packet 0xFFFF  is not linked to packet 0x0.  Now
application extracts packet 0xFFF0 through 0xFFFF. only when the linked
listed is empty (between recvFirst and recvNext) its recvLast and recvNext
pointers are nulliified  and the next incoming packet (0x5) will be
considered  recvFirst  and recvLast. This behaviour causes packets 0x0
through 0x4 to be discarded although they have entered ccRTP in correct
order.

This behaviour can be verified by using rtplisten and rtpsend apps. Modify
rtpsend to send 100 packets starting seqnum 0xFFF0. modify rtplisten to
sleep 10 seconds before ever attempting extracting packets.  using some
prints you will see that all its gets are packets 0xFFF0 through 0xFFFF.

fix:
recvFirst and recvLast serve as boundry pointers. To extract a packet you
iterate forward from recvFirst to recvFirst. To insert a packet you iterate
backwards from recvLast to recvFirst. A Natural fix will be to link packet
0xFFFF to packet 0x0 (special case), while not setting recvLast to 0x0 (in
order not to break the packet insertion condition based on < seqnum compare)
and only when (recvFirst==recvLast==0xFFFF and 0xFFFF is pointing to a 0x0
packet) to set recvFirst to 0x0 and recvLast to the last packet on the list.
this is a quirky fix with some of exceptions and not elegant at all. What do
you think?

Best Regards
Yaniv Levy

_______________________________________________
Ccrtp-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/ccrtp-devel