Yakir, 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 Regards, Didier Le Fri, 15 Jun 2018 04:52:07 +0000, Yakir Matusovsky <[email protected]> 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" > <[email protected]> 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" <[email protected]> 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 > _______________________________________________ Mailing list: https://launchpad.net/~rohc Post to : [email protected] Unsubscribe : https://launchpad.net/~rohc More help : https://help.launchpad.net/ListHelp
