rohc team mailing list archive

["Wong, Tak - 0665 - MITLL" <Tak.Wong@xxxxxxxxxx>]

Didier:

  All the incidents I sent you were TCP irregular chain.

>> But the rohc packet has no data after the timestamp (0x08).  So, a 
>> call to the tcp_opt_sack routine returns the ptr having been advanced, 
>> but no processing of the sack option is done, because the 
>> discriminator value is 0.

>I'm afraid I don't understand you well. The irregular encoding of the timestamp option cannot be 0-byte length (it may encoded from 2 to 8 bytes). And, why the tcp_opt_sack routine >read some ROHC bytes? Did you mean the tcp_opt_ts routine instead?

I think the timestamp field is OK.  We have an rohc_packet going into the routine tcp_irregular_tcp.  The routine processes the remaining data according to the current option list.
The remaining data itself is done after the 10 bytes of timestamp, but the option list continues.  Below is the exact option list when this problem occurs:

 	0x01 0x01 0x08 0x01 0x01 0x05 0xff 0xff
 	0xff   0xff   0xff   0xff  0xff   0xff 0xff 0xff

So, after processing NO-OP's (0x01 0x01), then the 10 bytes of timestamp (0x08).  At that point, there is nothing in the remain_data.  But the routine sees the
0x01 0x05 in the option list and does a NO-OP and then, for 0x05, calls the tcp_opt_sack routine.   In the tcp_opt_sack_routine, the first byte of the remain_data
is checked as discriminator.  But this is really the end of remain_data and the discriminator is 0.  Then the ptr is advanced by one.  When the ptr is returned, the
length is actually advanced beyond the roch_packet, eventually causing an assertion.   I think either the call to tcp_opt_sack, or the routine itself should check the
remain_data length before advancing the ptr.  However, this should not happen at all, if the option list is consistent with the rohc_packet.  With this packet, the
option list should just be

	0x01 0x01 0x08  0x01 0xff 0xff  0xff 0xff
 	0xff   0xff   0xff   0xff  0xff   0xff 0xff 0xff

Thanks and kind regards,

TW