← Back to team overview

rohc team mailing list archive

Re: Compression forced down to IR state



I've looked at it. There is indeed some problems in case of heavy loss.

I fixed the problems in a dedicated development branch. It should
solve your problem. Could you please give it a try?

The branch 'dev_be_more_robust_to_pkt_loss' is available on Github.
You may retrieve the source code and build it as follow:
 $ git clone https://github.com/didier-barvaux/rohc.git
 $ git co dev_be_more_robust_to_pkt_loss
 $ ./autogen.sh
 $ ./configure <your options>
 $ make all


Le Fri, 15 Jun 2018 04:52:07 +0000,
Yakir Matusovsky <yakir.matusovsky@xxxxxxxxxxx> a écrit :

> Hi, following up any insight over the sent capture? Any additional
> info about the system required?
> Regards,
> Yakir 
> On 11/06/18, 10:01 AM, "Yakir Matusovsky"
> <yakir.matusovsky@xxxxxxxxxxx> wrote:
>     I've attached the capture. I thought my team's previous
> experiment was quite heavy for the network to handle, so it might
> have been stuck for other reasons. Made the rate twice slower,
> capture is attached. Maybe this is to do with my traffic, sides
> report lots of BAD CRC and MALFORMED though don't get stuck.
> +Re-rohc_sniffer+ Can't build rohc_sniffer, when try building with
> for gcc, I get stuck into general rohc-2.1.0 build issue. This is it,
> test_tcp_ts_opt.c: In function ‘main’: test_tcp_ts_opt.c:143:26:
> error: array type has incomplete element type ‘struct CMUnitTest’
> const struct CMUnitTest tests[] = { 
>     Strange, as I did build it with cmocka-0.3.2 before and it
> doesn't have CMUnitTest struct?! Might be an inclusion problem and
> change is sources, e.g. cmocka.h.  I reckon one thing which can
> explain it, that I've started using cmocka-1.1.1 as well, for other
> apps. A mix-up maybe... The most annoying thing here is, that even
> when tried to change the cmocka to 1.1.1 it persists in
> configure/build scripts of the rohc-2.1.0 package. I am not sure how
> to clean the library properly, please advise? Regards, Yakir On
> 10/06/18, 1:15 AM, "Didier Barvaux" <didier@xxxxxxxxxxx> wrote: 
>         >Nope. I did not enable it in features and I do set arrival
>         >time before compress4. I now see that I should have enabled
>         >it but that wouldn't have helped me much as I'd originally
>         >intended this for traffic moving in O-Mode. From reading the
>         >lib code, I see this is done only for U-Mode, which makes
>         >sense. Correct?  
>         Yes, your understanding is correct. Regular context refreshes
> are not used in O-Mode. 
>         > Anyway, my O-Mode sessions do get
>         >stuck sometimes, e.g. when opening a remote SSH/TCP and
>         >doing e.g. "top" every sec in it. Originally, I thought to
>         >quickly try that "time refresh" to maybe find why the
>         >contexts get stuck(?) in this state.  
>         Are there any decompression failures reported by the
> rohc_decompress3() function? 
>         Is the problem reproducible ? If yes, please send me a
> network capture of the uncompressed SSH session that gets stuck. 
>         You may also run the sniffer application (found under
> app/sniffer/ in library sources) to check the correct
> compression/decompression of any traffic captured on a given network
> interface. All streams are recorded on disk, so in case of failure,
> the faulty stream may be used for analysis/debug. See
> https://rohc-lib.org/support/documentation/API/rohc-man-2.2.0/man1/rohc_sniffer.1.html
> for more information. Regards, Didier 

Follow ups