rohc team mailing list archive

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

Didier:

   Thanks for the analysis.  The option list I sent you is the content of tcp_context->tcp_opts_list_struct.   I went through a similar analysis of the
packet with decode_irregular_tcp, and I found the opts list struct content not matching the packet's options.  It is difficult to capture the exact
original TCP packet that causes the problem at decompression, as this problem only occurs when hundreds of thousands of packets have been
transmitted at high speed.  I will try to figure out a way to capture that.

   By the way, if I disable the timestamps and sack options, this particular problem goes away, but I am seeing a lot of PAWS (Protection Against Wrapping Sequence)
after that.  Now that is very strange, as this can only occur when a really old duplicated ack shows up with a matching sequence to the current sequence.  The chances
of this occurring is very small.  I use the default wlsb_width of 4.  Could that be too small for a high-rate transmission.  I tried to extend the wlsb_width to 8 or 16, but these
cause failures with decompressing SEQ_5 packets.

Thanks,

TW

-----Original Message-----
From: Rohc [mailto:rohc-bounces+tak.wong=ll.mit.edu@xxxxxxxxxxxxxxxxxxx] On Behalf Of Didier Barvaux
Sent: Friday, April 11, 2014 2:45 PM
To: rohc@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Rohc] ROHC TCP dynamic field changes

Hello,

>         Incoming ROHC packet (supposed to be a SACK):
> 
> 	0xfa 0x8f 0xf4 0x00 0xb2 0x6f 0x83 0x56
> 	0x4a 0x27 0xd8 0x29 0x1d 0x19 0xed 0x85
> 	0x28 0x49 0xc5 0xba 0x4a 0xc5 0xba 0x4a
> 	0x01 0x0b 0x50 0x05 0xa8

Let's analyze the packet:
 * byte 0xfa:
    * the ROHC packet is in CO common format
    * ttl_flag = 0
 * byte 0x8f:
    * ack_flag = 1
    * psh_flag = 0
    * rsf_flag = 0
    * MSN = 15
 * byte 0xf4:
    * seq_indicator = 3
    * ack_indicator = 3
    * ack_stride_indicator = 0
    * window_indicator = 1
    * ip_id_indicator = 0
    * urg_ptr_present = 0
 * byte 0x00:
    * reserved = 0
    * ecn_used = 0
    * dscp_present = 0
    * ttl_hopl_present = 0
    * list_present = 0
    * ip_id_behavior = 0
    * urg_flag = 0
 * byte 0xb2:
    * df = 1
    * CRC = 0x32
 * bytes 0x6f 0x83 0x56 0x4a
    * 32-bit sequence number = 0x6f83564a
 * bytes 0x27 0xd8 0x29 0x1d
    * 32-bit ACK number = 0x27d8291d
 * bytes 0x19 0xed
    * 16-bit window = 0x19ed
 * bytes 0x85
    * 8-bit IP-ID LSB = 0x85
This is the end of the CO common base header. Now, let's analyze the irregular chain:
 * ipv4_irregular is empty
 * tcp_irregular
    * bytes 0x28 0x49
       * TCP checksum = 0x2849 (tcp_irregular)
 * nop_irregular is empty
 * nop_irregular is empty
 * tsopt_irregular
    * bytes 0xc5 0xba 0x4a
       * discriminator = '110'
       * tsval = 0x5ba4a
    * bytes 0xc5 0xba 0x4a
       * discriminator = '110'
       * tsecho = 0x5ba4a
 * sack1_irregular
    * byte 0x01
       * discriminator = '00000001'
    * block_1
       * block_start = 0x0b 0x50
          * discriminator = '0'
          * sack_field = 0x0b50
       * block_end = 0x05 0xa8
          * discriminator = '0'
          * sack_field = 0x05a8

I made some hypothesis about the structure of the list of TCP options:
  NOP + NOP + Timestamp + SACK + NOP + NOP Is my hypothesis right?

The above analysis seems to show that indeed the tcp_irregular decoding is wrong, more especially the sack1_irregular decoding. The following bytes are malformed:
  0x02 0x1c 0x48 0x05 0xa8 0x0b 0x50 0x05 0xa8 They should probably be something like:
  0x05 0x0a 0x27 0xd8 0x34 0x6d 0x27 0xD8 0x3A 0x15 0x01 0x01 If you got the original uncompressed packet, please check against it.

The CO common format doesn't contain all the information about the uncompressed packet, so the ROHC library cannot decompress it without the previous IR packets. If you can provide them to me, I could test it further. See the thread [1] where the person provided me the full flow and I was able to reproduce his/her problem quickly.

[1] https://answers.launchpad.net/rohc/+question/245791
  


>      The option list:
> 
> 	0x01 0x01 0x08 0xff 0xff 0xff 0xff 0xff
> 	0xff 0xff 0xff  0xff 0xff  0xff  0xff  0xff

Hmm, I think that I finally discovered what your "option list" is. It looks like the content of the tcp_context->tcp_options_list or tcp_context->tcp_opts_list_struct buffers, not the content of the uncompressed or compressed packet. That's why I said that the list was malformed. Am I right?


Regards,
Didier

_______________________________________________
Mailing list: https://launchpad.net/~rohc
Post to     : rohc@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~rohc
More help   : https://help.launchpad.net/ListHelp