Ethernet transport app for ROHC Pkts

Asked by Raman Gupta on 2012-11-30

I was trying to write a Ethernet based transport app similar to rohctunnel(tunnel.c) on 1.4.1 release. After some testing with a few RTP pcaps I found that Ethernet's minimum payload is 46 bytes and it adds padding for any payload less than that size. Thus decompression fails due to CRC mismatch for pkts less than minimum size. Since ROHC depends upon lower layer to give the length information which Ethernet header does not provide(cannot use EtherType for length) so I am thinking to add length byte infront of compressed ROHC pkt similar to current sequence bytes, before sending it on Ethernet. Other end will read this as length of compressed pkt instead of length returned by Ethernet interface.

If I replace sequence bytes with length byte what impact it will have? Any other thoughts on this issue.

Question information

Language:
English Edit question
Status:
Solved
For:
rohc Edit question
Assignee:
No assignee Edit question
Solved by:
Didier Barvaux
Solved:
2012-12-04
Last query:
2012-12-04
Last reply:
2012-12-03

> If I replace sequence bytes with length byte what impact it will have? Any other thoughts on this issue.

The sequence bytes in the ROHC tunnel application are used to detect (emulated) packet loss, and compute some statistics about it. The ROHC tunnel application and the ROHC library do not rely on them.

Regards,
Didier

Raman Gupta (ramangupta16) said : #2

> The sequence bytes in the ROHC tunnel application are used to detect (emulated) packet loss, and > compute some statistics about it. The ROHC tunnel application and the ROHC library do not rely on > them.

OK.

I am trying to follow steps mentioned in Wiki on "How to modify / enhance the ROHC library". Steps:
1) Downloaded and installed Bazaar on my CentOS 5.5 64-bit system.
2) To get a fresh copy of ROHC library source code I did 'bzr branch lp:rohc'
3) Then entered the 'rohc' subdirectory and tried ./configure command but it failed to find configure file.

Am I doing it the right way?

Hello,

Run ./autogen.sh script instead of ./configure script if you use a development version from Bazaar.

I added this note on the wiki: http://rohc-lib.org/wiki/doku.php?id=library-install-sources&#native_build_on_unix-like_systems

Regards,
Didier

Raman Gupta (ramangupta16) said : #4

On running ./autogen.sh I got the error and it stopped from further progress:-

$ ./autogen.sh
Running aclocal... done
Running libtoolize... done
Running autoconf... failed
Running autoconf again with errors unmasked:
configure.ac:122: warning: AC_CANONICAL_HOST invoked multiple times

Sorry, the tools provided by CentOS 5.5 are too old for the ./autogen.sh script. Either use the 1.5.0 version of library (that provides the ./configure script) or run ./autogen.sh on another system (with up to date tools) before using it on the CentOS 5.5 system.

Regards,
Didier

Raman Gupta (ramangupta16) said : #6

Thanks for the information about older versions of build tools, I have updated to following versions of build tools to fix the problem: autoconf 2.68, automake 1.11.2, libtool 2.2.2

However now I face a complilation issue upon doing make:-

In file included from test_performance.c:93:
../../src/common/protocols/ipv6.h:47:1: error: "s6_addr" redefined
In file included from /usr/include/arpa/inet.h:23,
                 from test_performance.c:73:
/usr/include/netinet/in.h:201:1: error: this is the location of the previous definition

This seems to be same as Question #212737 (Redefinition of s6_addr in Linux environnement).

Raman Gupta (ramangupta16) said : #7

I will also update wiki with these correct versions of build tools, which enabled me to run autogen.sh script for development version of code.

Raman Gupta (ramangupta16) said : #8

Thanks Didier Barvaux, that solved my question.

I fixed the build problem in main branch. See http://bazaar.launchpad.net/~didier-barvaux/rohc/main/revision/614

Regards,
Didier

Raman Gupta (ramangupta16) said : #10

Thanks for ur changes. Now build passes fine.

I am new to bazaar version management system so please help me to update my branch. I did following on my local CentOS system

Step 1) bzr branch lp:rohc //This is as per wiki to get a fresh copy of the source code
Step 2) bzr update // Tree is up to date at revision 612 of branch /home/rgupta/rohc/sandbox/rohc
Step 3) bzr merge //This merged ur changes.
Step 4) bzr status -v //Shows ur changes as modified files :-
$ bzr status -v
modified:
  app/sniffer/sniffer.c
  src/common/ip.h
  src/common/protocols/ipv6.h
  src/decomp/d_generic.c
  src/decomp/rohc_decomp.c
pending merges:
  Didier Barvaux 2012-12-07 Fix bug #decompressor: compressed list with 8-...
    Didier Barvaux 2012-12-07 Fix bug #1087682: decompressor: zero-lengt...
    Didier Barvaux 2012-12-06 Avoid s6_addr clash between src/common/pro...
    Didier Barvaux 2012-12-04 Sniffer: improve statistics report for a l...

Now do I need to checkin/commit these changes in my local working tree here?
What is the correct sequence to get latest changes from the main branch?

Step 5) $ bzr info
Standalone tree (format: 2a)
Location:
  branch root: .
Related branches:
  parent branch: http://bazaar.launchpad.net/~didier-barvaux/rohc/main/
$

After this I build and it was fine.

Hello,

If you didn't modified anything locally, the simplest way to keep in sync is the command 'bzr pull'. If you changed something locally, 'bzr pull' does not work and 'bzr merge' is required.

If you are in the first case (no local modification):
 $ bzr revert
 $ bzr pull
And you are up to date.

More info on bazaar here:
 - tutorial: http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
 - part about 'bzr merge' : http://doc.bazaar.canonical.com/latest/en/mini-tutorial/#updating-your-branch-from-the-main-branch

Regards,
Didier

Raman Gupta (ramangupta16) said : #12

I trying to add the Ethernet based transport app similar to rohctunnel using release 1.5.1 .

Is adding new app in Makefile.am not sufficient? Do I need to make changes in Makefile.in also?

Hello,

You need to modify:
 - app/<your_app_name>/Makefile.am # look at other apps' Makefile.am file
 - app/Makefile.am # add the name of the new subdir
 - configure.ac # add app/<your_app_name>/Makefile to AC_CONFIG_FILES()

Then run the ./autogen.sh script.

Regards,
Didier

Raman Gupta (ramangupta16) said : #14

Hello,
 I have build an app which is an Ethernet based transport application very similar to rohctunnel on the trunk. The major highlights are:-
1) It directly uses Ethernet as transport and thus is pont-to-point and cannot traverse routers/gateways.
2) Since Ethernet's minimum payload is 46 bytes and kernel adds padding for any payload less than that size, thus I have added a length byte after sequence bytes before sending it on Ethernet. Other end will read this byte as the length of ROHC packet instead of length returned by Ethernet interface.

How to send the diff to you for review and commit? Wiki is currently not working, for me to refer it for exact instructions.

--Raman

Raman,

Sorry for the website/wiki downtime. I made a mistake with server configuration.

See these wiki page for information about patch submit: http://rohc-lib.org/wiki/doku.php?id=library-hacking

If you need additional information, tell me.

Regards,
Didier

Raman Gupta (ramangupta16) said : #16

I have submitted the ethTunnel Patch to mailing list.

Raman,

I've seen it. Thank you.

Regards,
Didier

Raman Gupta (ramangupta16) said : #18

I have a question:- Can we clear a Context after we are done with its usage?

Description:-
--------------
For RTP profile, a new ContextID is created for a new pair of source/destination UDP ports representing a RTP stream. Once this RTP stream closes i.e. source/destination pair UDP ports are closed, is there a way to clear the allocated context also so that next time when the same pair of source/destination UDP ports is assigned to a new RTP stream then it is allocated a fresh context with no dependency on previous context. Using the same context for new RTP stream (having same ports) causes failures/errors between compressor-decompressor contexts.

Raman,

> Can we clear a Context after we are done with its usage?

You cannot clear one compression context, however you can clear all
compression contexts at once (after a disconnection/reconnection for
example). See function rohc_comp_force_contexts_reinit() in main
branch. The function is not available in versions 1.5.x or later.

> Using the same context for new RTP stream (having same ports)
> causes failures/errors between compressor-decompressor contexts.

It should not. The ROHC protocol and the ROHC library support such
behaviours. Please report a bug with the 2 RTP streams.

Regards,
Didier