RTP and UDP Packets are been incorrectly decompressed while using the profiles : 0x0101 AND 0x0102

[Poonam Ghosh]

WE are using the ROHC libraries for one of the aeronautical companies as per the requirements to handle the Robust Header Compression and Decompression features with the https://rohc-lib.org/

While testing the Compression and Decompression functionalities we have found the following issues:

1. Profiles used : ROHCv2_PROFILE_IP_UDP_RTP
2. Orinigal Packet Dump as shown below:

dump rohc packet of len 60
0x45 0x00 0x00 0x3c 0x00 0x00 0x00 0x00
0x40 0x11 0x7c 0xaf 0x7f 0x00 0x00 0x01
0x7f 0x00 0x00 0x01 0x04 0xd3 0x04 0xd2
0x00 0x28 0x00 0x00 0x80 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x68 0x65 0x6c 0x6c 0x6f 0x2c 0x20 0x50
0x79 0x74 0x68 0x6f 0x6e 0x20 0x77 0x6f
0x72 0x6c 0x64 0x21

3. Decompressed buffer Dump as shown below which doesn't matches with the Original Packet sent:
4. There are huge difference in the Payload part of the UDP dump from the Original Packet sent.
dump decomp output buffer length 60

0x45 0x00 0x00 0x3c 0x00 0x00 0x00 0x00
0x40 0x11 0x7c 0xaf 0x7f 0x00 0x00 0x01
0x7f 0x00 0x00 0x01 0x04 0xd3 0x04 0xd2
0x00 0x28 0x00 0x00 0x80 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x6f 0x2c 0x20 0x50
0x79 0x74 0x68 0x6f 0x6e 0x20 0x77 0x6f
0x72 0x6c 0x64 0x21

Similar issue is seen with Profile ROHCv2_PROFILE_IP_UDP
Kindly prioritize the fixing of the above issue or suggest if there are similar issues in past and its available in any of the LATEST releases.

[Poonam Ghosh (poonam-ghosh)]

Kindly suggest a workaround to handle the above issue.

[Didier Barvaux (didier-barvaux)]

Hello,

Thank you for the bug report. I did not open the attached zip archive yet.

The IPv4, UDP and RTP look good. The RTP payload looks good too, except for the 4 first bytes that all zeroes. Is it correct?

If yes, that is quite strange since payload is seldom impacted by bugs. The best way to find the root of your problem is to reproduce it on my setup.

Is the bug 100% reproducible in your setup?
Is it the first packet of flow? If no, is it possible to get a PCAP file with the first packets?
Do you use the default parameters of the library? If not, please give me the changed parameters.
What is the architecture of your setup?

Regards,
Didier

[Poonam Ghosh (poonam-ghosh)]

First of all thanks Didier for the response, we need your inputs for fixing this issue for our end-user customer who needs this ROHC enabled with support of the features.
To give you a background on the architecture, we are building a LTE network solution for the terrestrial Infrastructure for one leading SATCOM manufacturers and solution providers.
They are looking for using Open source solution to help support the Robust Header Compression, Decompression for the following streams: UDP IP, TCP IP and RTP UDP IP.
We have integrated your libraries to enable the ROHC in Uplink data flow and Downlink flow and that should ideally work seamless by virtue of the Specification. There should ideally be no call drops or drop in the bandwidth of the data or voice services if ROHC is enabled. Hope you now understand the architecture and capability needed.

Here are my answers marked with Inline [Poonam Ghosh]

The IPv4, UDP and RTP look good. The RTP payload looks good too, except for the 4 first bytes that all zeroes. Is it correct?
[Poonam Ghosh] No that's incorrect, we are expected to see the same payload in the dump (post decompress) as sent in the Original Data Packet.

If yes, that is quite strange since payload is seldom impacted by bugs. The best way to find the root of your problem is to reproduce it on my setup.

Is the bug 100% reproducible in your setup?

[Poonam Ghosh] Yes the issue 100% reproducible if you use the same configuration and the profile we have used with the Data Dump.

Is it the first packet of flow? If no, is it possible to get a PCAP file with the first packets?
[Poonam Ghosh] IT is the first and only packet what we are testing with the Profile: ROHCv2_PROFILE_IP_UDP_RTP

Do you use the default parameters of the library? If not, please give me the changed parameters.
[Poonam Ghosh] I have attached the Original (INPUT) packet dump used for calling the compress function.

What is the architecture of your setup?
[Poonam Ghosh] Shared with you on top. Let me know if you need any additional inputs.

Thanks & Regards
Poonam Ghosh

[Poonam Ghosh (poonam-ghosh)]

Attached the Packet dump for reproduction.

Issue is seen only with Profiles IP_UDP and IP_UDP_RTP

[Didier Barvaux (didier-barvaux)]

Hello,

Thank you for the answers. It tried to reproduce the problem without success :-/

I created a PCAP file with Scapy as follow:

  $ scapy
  Welcome to Scapy (2.3.2)
  >>> p=[]
  >>> p.append(Ether(type=0x0800)/Raw(load='\x45\x00\x00\x3c\x00\x00\x00\x00\x40\x11\x7c\xaf\x7f\x00\x00\x01\x7f\x00\x00\x01\x04\xd3\x04\xd2\x00\x28\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x68\x65\x6c\x6c\x6f\x2c\x20\x50\x79\x74\x68\x6f\x6e\x20\x77\x6f\x72\x6c\x64\x21'))
  >>> wrpcap('bug1993596.pcap', p)
  WARNING: Mac address to reach destination not found. Using broadcast.
  >>> Ctrl+D

I checked its content as follow:
  $ tcpdump -r ./bug1993596/bug1993596.pcap -xxx
  reading from file ./bug1993596/bug1993596.pcap, link-type EN10MB (Ethernet), snapshot length 65535
  14:23:24.472263 IP heka.barvaux.org.1235 > heka.barvaux.org.1234: UDP, length 32
        0x0000: ffff ffff ffff 0000 0000 0000 0800 4500
        0x0010: 003c 0000 0000 4011 7caf 7f00 0001 7f00
        0x0020: 0001 04d3 04d2 0028 0000 8000 0000 0000
        0x0030: 0000 0000 0000 6865 6c6c 6f2c 2050 7974
        0x0040: 686f 6e20 776f 726c 6421

Then, I checked out and built the 2.3.1 release:

  $ git co rohc-2.3.1
  HEAD is now at 8d00cde3b Update ChangeLog for release 2.3.1
  $ git describe --tags
  rohc-2.3.1
  $ ./autogen.sh && make clean && make -j10 all && make -j10 check
  [...]

Then, I ran one of the test tool of the ROHC library that compresses then uncompresses any packet that is given as PCAP. The tool permits some configuration choices on command line. The tool was launched as follow (use ROHCv2, do not compare generated ROHC packets against a reference PCAP since I have none, verbose mode, output ROHC packets into ./bug1993596/bug1993596.rohc.pcap, use Small CIDs):

  $ ./test/non_regression/test_non_regression \
      --rohc-version 2 \
      --no-comparison \
      --verbose \
      -o ./bug1993596/bug1993596.rohc.pcap \
      smallcid \
      ./bug1993596/bug1993596.pcap \
    > ./bug1993596/bug1993596.log
  $ echo $?
  0

Looking at ./bug1993596/bug1993596.log, one can notice some interesting parts:

[...]
=== ROHC compression: start
[DEBUG] [rohc_traces_internal.c:111 rohc_dump_buf()] uncompressed data, max 100 bytes (60 bytes):
[DEBUG] [rohc_traces_internal.c:120 rohc_dump_buf()] 45 00 00 3c 00 00 00 00 40 11 7c af 7f 00 00 01
[DEBUG] [rohc_traces_internal.c:120 rohc_dump_buf()] 7f 00 00 01 04 d3 04 d2 00 28 00 00 80 00 00 00
[DEBUG] [rohc_traces_internal.c:120 rohc_dump_buf()] 00 00 00 00 00 00 00 00 68 65 6c 6c 6f 2c 20 50
[DEBUG] [rohc_traces_internal.c:140 rohc_dump_buf()] 79 74 68 6f 6e 20 77 6f 72 6c 64 21
[...]
[DEBUG] [rohc_comp.c:877 rohc_comp_get_profile_l4()] ROHCv2 IP/UDP/RTP profile is possible
[DEBUG] [rohc_comp.c:885 rohc_comp_get_profile_l4()] source port = 1235
[DEBUG] [rohc_comp.c:888 rohc_comp_get_profile_l4()] destination port = 1234
[DEBUG] [rohc_comp.c:891 rohc_comp_get_profile_l4()] SSRC = 0x00000000
[DEBUG] [rohc_comp.c:691 rohc_comp_get_profile()] profile 'ROHCv2 IP/UDP/RTP' (0x0101) will be used to compress the packet
[...]
[DEBUG] [comp_rfc5225_ip_udp_rtp.c:1400 rohc_comp_rfc5225_ip_udp_rtp_decide_pkt()] code IR packet...

[Didier Barvaux (didier-barvaux)]

Please find attached the PCAP file created with Scapy.

[Poonam Ghosh (poonam-ghosh)]

The issue is fixed in our local / private repository by fixing the simulated Test Cases (for Compressing / Decompressing) handling as per the customer's requirement.
We have not added any changes in the ROHC libraries.

I am closing this issue for further debugging or RCA.