rohc team mailing list archive

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

Didier:

  Here are a few packets I captured that caused the issues I sent to you:

packet before compression:

0x45 0x00 0x00 0x40 0xbf 0x4d 0x40 0x00
0x40 0x06 0x53 0x54 0x0a 0x0a 0x0a 0x01
0x0a 0x0a 0x0a 0x02 0x13 0x88 0xd9 0x03
0xe7 0x39 0xed 0x78 0xfb 0x15 0x47 0xd4
0xb0 0x10 0x21 0xc3 0x28 0x49 0x00 0x00
0x01 0x01 0x08 0x0a 0x00 0x22 0x71 0xbe
0x00 0x22 0x71 0xbe 0x01 0x01 0x05 0x0a
0xfb 0x15 0x75 0x14 0xfb 0x15 0x80 0x64

Compressed packet:

0xaf 0xed 0x78 0xe1 0x28 0x49 0xc2 0x71
0xbe 0xc2 0x71 0xbe 0x01 0x2d 0x40 0x0b
0x50

feedback:

0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00


On the decompressor side, the current option list (content from opt_lis_struct):

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



Here is another one:

packet before compression:

0x45 0x00 0x00 0x48 0xbf 0x5e 0x40 0x00
0x40 0x06 0x53 0x3b 0x0a 0x0a 0x0a 0x01
0x0a 0x0a 0x0a 0x02 0x13 0x88 0xd9 0x03
0xe7 0x39 0xed 0x78 0xfb 0x15 0x80 0x64
0xd0 0x10 0x20 0xe6 0x28 0x51 0x00 0x00
0x01 0x01 0x08 0x0a 0x00 0x22 0x71 0xbe
0x00 0x22 0x71 0xbe 0x01 0x01 0x05 0x12
0xfb 0x15 0x64 0x1c 0xfb 0x15 0x69 0xc4
0xfb 0x15 0x86 0x0c 0xfb 0x15 0x91 0x5c

Compressed packet:

0xaf 0xed 0x78 0xf4 0x28 0x51 0xc2 0x71
0xbe 0xc2 0x71 0xbe 0x02 0xff 0xff 0xff
0xe3 0xb8 0x05 0xa8 0x05 0xa8 0x0b 0x50

feedback:

0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

On the decompressor side, the opt list contents are:

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


Thanks in advance,

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