TCP

> when will the release 1.7.0 lib with TCP profile come out?

I don't know exactly. Some work remains to do about the new API.

> if it is long time to see it, is there some newest debug code
> about TCP profile? if so, where is it?

The code of the future 1.7.0 release (with TCP profile included) is available in the main branch:
https://code.launchpad.net/~didier-barvaux/rohc/main

Regards,
Didier

Thanks Didier Barvaux, that solved my question.

Hello Didier,
          I use the TCP code from the ''https://code.launchpad.net/~didier-barvaux/rohc/main'' As you said above,However, it seems can not decompress some TCP Rohc packets successfully. Here is an IR rohc packet of TCP-IP profile, I get it from a LTE UE equipment, can you see why it is decompressed unsuccessfully, Thank you very much.

an IR TCP packet:
FD06F600 06C0A895 6A0A0A02 0209BE20
FB040080 489F3002 00018B63 E0ECFFFF
75F706A8 B88D05AC 01

Regards,
CXS

Hello,

I tested to decode the packet with small CIDs and code at revision 1027. Decompression fails in the dynamic chain of TCP options:

[d_tcp.c:2394 tcp_decode_dynamic_tcp()] parse TCP dynamic part
[d_tcp.c:2414 tcp_decode_dynamic_tcp()] TCP res_flags = 0, ecn_flags = 0, rsf_flags = 2, URG = 0, ACK = 0, PSH = 0
[d_tcp.c:2425 tcp_decode_dynamic_tcp()] MSN = 0x0001
[d_tcp.c:2450 tcp_decode_dynamic_tcp()] tcp = 0x804e534, seq_number = 0x8b63e0ec, ack_number = 0x0
[d_tcp.c:2465 tcp_decode_dynamic_tcp()] TCP window = 0xffff
[d_tcp.c:2480 tcp_decode_dynamic_tcp()] TCP checksum = 0x75f7
[d_tcp.c:2503 tcp_decode_dynamic_tcp()] TCP urg_ptr = 0x0000
[d_tcp.c:2534 tcp_decode_dynamic_tcp()] TCP ack_stride = 0x0000, ack_number_residue = 0x0000
[d_tcp.c:2597 tcp_decode_dynamic_tcp()] TCP options list: 6 4-bit indexes transmitted on 3 bytes
[d_tcp.c:2643 tcp_decode_dynamic_tcp()] TCP options list: XI #0: item for index 2 is present
[d_tcp.c:2660 tcp_decode_dynamic_tcp()] TCP options list: XI #0: item for index 2 is a known index
[d_tcp.c:2676 tcp_decode_dynamic_tcp()] TCP option type 0x05 (5)
[d_tcp.c:2717 tcp_decode_dynamic_tcp()] TCP option is 172-byte long (type and length fields included)
[d_tcp.c:2740 tcp_decode_dynamic_tcp()] malformed TCP dynamic part: malformed TCP option items: only 1 bytes available while at least 170 bytes required for next option
[d_tcp.c:1025 d_tcp_decode_ir()] malformed ROHC packet: malformed TCP dynamic part
[d_tcp.c:794 d_tcp_decode()] return -5
[rohc_decomp.c:1518 d_decode_header()] failed to decompress packet (code = -5)

Please send me the original, uncompressed TCP packet. I'll be able to determine if the ROHC packet is really malformed or if you hit a bug in the ROHC library. The TCP profile is in beta state, so the 2nd option probably the right answer :)

Regards,
Didier

sorry, our ue equipment is taken now, I can not get the the original, uncompressed TCP packet today, I can use it tomorrow. Thank you. PS: the TCP rohc packet compressed by our ue equipment are usually right.

Our UE equipment is given back this afternoon, so I get the datas now.
another IR TCP packet and its corresponding uncompressed TCP packet is as follows respectively:

IR(length 41)
FD06FC00 06C0A895 6A0A0A02 020B0020
FB040080 536E3002 00019934 219CFFFF
263506A8 B88D05AC 01

The corresponding uncompressed TCP packet (length 52)
45000034 536E4000 80064537 C0A8956A
0A0A0202 0B0020FB 9934219C 00000000
8002FFFF 26350000 020405AC 01030301
01010402

can you see why the IR packet is decompressed unsuccessfully with the revision 1027code,Thank you very much.

Regards,
cxs

Hello,

Thank you for the uncompressed/compressed couple. I found several problems in the TC profile of the ROHC library:

1/ The IP-ID of the IPv4 header is wrongly considered as random
     at the very beginning of a TCP stream. Fix is easy. It is not the
     problem that makes the decompressor fail to decompress
     the TCP IR packet generated by the equipment.

2/ The way the TCP options are compressed/decompressed is not
     conform to the RFC. The full options are transmitted while some
     bytes could be avoided. Fix requires a little more time. I'll work on
     it in next days.

Once those problems are fixed, I'll appreciate if you could perform the test with the UE equipment again. Maybe other bugs will be discovered. What is the product name and manufacturer?

Regards,
Didier

Hello,
          I am looking forward to your repaired ROHC library, I will test it with the UE equipment again. our UE equipment is named "TM500(LTE)", which is made by Aeroflex company.

Regards,
cxs

Hello,

I made some progress. I modified the ROHC library: it is able to generate the same TCP IR packet that the Aeroflex equipment. I'll made the decompression part tomorrow.

Regards,
Didier

Hello,
If you finish your modifing the lib, please tell me where the new code is located,because the site ''https://code.launchpad.net/~didier-barvaux/rohc/main'' is not available,I will test it with the Aeroflex UE equipment again. Thank Didier.

Regards,
cxs

Hello,

I have just finished the required modifications. All the library tests run fine with the changes. Your TCP packet is successfully compressed/decompressed (with the same ROHC format).

It would be great if you could test the changes with your LTE equipment :-)

The patch is attached to the related ticket in the bug tracker. Direct link:
  https://bugs.launchpad.net/rohc/+bug/1301518/+attachment/4063561/+files/bug1301518.patch

Download it, then apply it on sources (at revision 1027):
  $ patch -p0 < /path/to/patch/bug1301518.patch
  $ make

Regards,
Didier

Hello,

    Unfortunately, the TCP communication between Aeroflex equipment and your new lib is still not successful as before. Yes, it can decompress the first TCP IR packet, However, the second TCP packet was decompressed unsuccessfully, the third TCP packet was decompressed successfully, but the fourth TCP packet was decompressed unsuccessfully, the fifth success, badly, all the tcp packets after the fifth packet were decompressed unsuccessfully.can you find out what the reason is, Thanks.
     the first six TCP ROHC packets and their corresponding uncompressed TCP packet are listed respectively:
1.FD068C00 06C0A891 780A0A02 02135D20
   FB040080 06693002 000145D7 F79AFFFF
   9F2806A8 B88D05AC 01

   45000034 06694000 8006962E C0A89178
   0A0A0202 135D20FB 45D7F79A 00000000
   8002FFFF 9F280000 020405AC 01030301
   01010402
2.E3FD0612 0006C0A8 91780A0A 02021363
   20FB0400 8006A230 02000181 7F2063FF
   FF3AB206 A8B88D05 AC01

   45000034 06A24000 800695F5 C0A89178
   0A0A0202 136320FB 817F2063 00000000
   8002FFFF 3AB20000 020405AC 01030301
   01010402
3.FD069100 06C0A891 780A0A02 02135D20
   FB060080 099B3002 000245D7 F79AFFFF
   9F2806A8 B88D05AC 01

   45000034 099B4000 800692FC C0A89178
   0A0A0202 135D20FB 45D7F79A 00000000
   8002FFFF 9F280000 020405AC 01030301
   01010402
4.E3FD066E 0006C0A8 91780A0A 02021363
   20FB0600 8009D630 02000281 7F2063FF
   FF3AB206 A8B88D05 AC01

   45000034 09D64000 800692C1 C0A89178
   0A0A0202 136320FB 817F2063 00000000
   8002FFFF 3AB20000 020405AC 01030301
   01010402
5.FD06F700 06C0A891 780A0A02 02135D20
   FB060080 10073002 000345D7 F79AFFFF
   9F2806A8 B88D05AC 01

   45000034 10074000 80068C90 C0A89178
   0A0A0202 135D20FB 45D7F79A 00000000
   8002FFFF 9F280000 020405AC 01030301
    01010402
6.E3FD0630 0006C0A8 91780A0A 02021363
   20FB0600 80106330 02000381 7F2063FF
   FF3AB206 A8B88D05 AC01

    45000034 10634000 80068C34 C0A89178
    0A0A0202 136320FB 817F2063 00000000
    8002FFFF 3AB20000 020405AC 01030301
    01010402

With the patch I sent you, the ROHC library seems to decompress the 6 TCP packets fine. If you encounter a different behavior, could you please provide me the library logs so I can help you?

Hello,
      Sorry,there was an error for my experiment, the ROHC library can decompress the 6 TCP packets above. However, after successful compression and decompression more than ten TCP packets , decompression failures appear again, so the TCP Interactive communication between your lib (revision 1027) and the Aeroflex equipment failed in the end.
     The first two failed decompression rohc packets and their corresponding TCP packets are listed below,can you see it?Thanks.
1.(length: 22Bytes)
   E4FAB5BC 4CDFF74D 9EDAB3A5 0000FDB5
   0058A800 4CAE
   (length: 40Bytes)
   45000028 58A84000 80068C58 C0A8917C
   C0A80302 09630015 FC59F74D 9EDAB3A5
   5011FDB5 4CAE0000
2.(length: 15Bytes)
   E4FAB624 44E5B3A5 FDB56002 004CAE
   (length: 40Bytes)
   45000028 60024000 800684FE C0A8917C
   C0A80302 09630015 FC59F74D 9EDAB3A5
   5011FDB5 4CAE0000

Regards,
CXS

> The first two failed decompression rohc packets and their corresponding
> TCP packets are listed below,can you see it?Thanks.

The ROHC protocol is stateful. The compression of the 2 failed packets depends on the previous packets. Could you please send me all the packets from the start of the stream to the 1st failed packet?

Regards,
Didier

1.FD06D900 06C0A891 7C0A0A02 02095920
   FB040080 2B7B3002 0001151B D2D9FFFF
   FEA506A8 B88D05AC 01

   45000034 2B7B4000 80067118 C0A8917C
   0A0A0202 095920FB 151BD2D9 00000000
   8002FFFF FEA50000 020405AC 01030301
   01010402
2.FD068D00 06C0A891 7C0A0A02 02095920
   FB060080 2F073002 0002151B D2D9FFFF
   FEA506A8 B88D05AC 01

  45000034 2F074000 80066D8C C0A8917C
  0A0A0202 095920FB 151BD2D9 00000000
  8002FFFF FEA50000 020405AC 01030301
  01010402
3.FD06F200 06C0A891 7C0A0A02 02095920
   FB060080 36813002 0003151B D2D9FFFF
   FEA506A8 B88D05AC 01

   45000034 36814000 80066612 C0A8917C
   0A0A0202 095920FB 151BD2D9 00000000
   8002FFFF FEA50000 020405AC 01030301
   01010402
4.E3FD0666 0006C0A8 917C0A0A 02020962
  20FB0400 803B4330 02000154 EF5388FF
  FF3E1A06 A8B88D05 AC01

  45000034 3B434000 80066150 C0A8917C
  0A0A0202 096220FB 54EF5388 00000000
  8002FFFF 3E1A0000 020405AC 01030301
  01010402
5.E4FD06C7 0006C0A8 917CC0A8 03020963
   00150400 803B8730 020001FC 59F74CFF
   FF5C3106 A8B88D05 AC01

  45000034 3B874000 8006A96D C0A8917C
  C0A80302 09630015 FC59F74C 00000000
  8002FFFF 5C310000 020405AC 01030301
  01010402
6.E4FD0611 0006C0A8 917CC0A8 03020963
  00150400 803B91D0 100002FC 59F74D9E
  DAB37BFD CA4CC4B3 7B00

  45000028 3B914000 8006A96F C0A8917C
  C0A80302 09630015 FC59F74D 9EDAB37B
  5010FDCA 4CC40000
7.E4FD06C5 0006C0A8 917CC0A8 03020963
   00150600 803BD8D0 100003FC 59F74D9E
   DAB3A5FD B54CAF00 0000

   45000028 3BD84000 8006A928 C0A8917C
   C0A80302 09630015 FC59F74D 9EDAB3A5
   5010FDB5 4CAF0000
8. E3FD060E 0006C0A8 917C0A0A 02020962
    20FB0600 803EE030 020002554 EF5388FF
    FF3E1A06 A8B88D05 AC01

    45000034 3EE04000 80065DB3 C0A8917C
    0A0A0202 096220FB 54EF5388 00000000
    8002FFFF 3E1A0000 020405AC 01030301
    01010402
9. E5FD0688 0006C0A8 917C0A0A 02020965
    20FB0400 80452830 02000121 128E09FF
    FF377306 A8B88D05 AC01

   45000034 45284000 8006576B C0A8917C
   0A0A0202 096520FB 21128E09 00000000
   8002FFFF 37730000 020405AC 01030301
   01010402
10.E3FD06FC 0006C0A8 917C0A0A 02020962
    20FB0600 80463430 02000354 EF5388FF
    FF3E1A06 A8B88D05 AC01

    45000034 46344000 8006565F C0A8917C
    0A0A0202 096220FB 54EF5388 00000000
    8002FFFF 3E1A0000 020405AC 01030301
    01010402
11.E5FD06F0 0006C0A8 917C0A0A 02020965
     20FB0600 8048D830 02000221 128E09FF
     FF377306 A8B88D05 AC01

     45000034 48D84000 800653BB C0A8917C
     0A0A0202 096520FB 21128E09 00000000
      8002FFFF 37730000 020405AC 01030301
      01010402
12.E5FD0602 0006C0A8 917C0A0A 02020965
     20FB0600 80504430 02000321 128E09FF
     FF377306 A8B88D05 AC01

     45000034 50444000 80064C4F C0A8917C
     0A0A0202 096520FB 21128E09 00000000
     8002FFFF 37730000 020405AC 01030301
     01010402
13.E6FD063F 0006C0A8 917C0A0A 02020966
     20FB0400 8054EF30 0200015C 2E570CFF
     FF335306 A8B88D05 AC01

     45000034 54EF4000 800647A4 C0A8917C
     0A0A0202 096620FB 5C2E570C 00000000
     8002FFFF 33530000 020405AC 01030301
     01010402
14.E4FD06FE 0006C0A8 917CC0A8 03020963
     00150600 805502D0 110004FC 59F74D9E
     DAB3A5FD B54CAE00 0000

     45000028 55024000 80068FFE C0A8917C
     C0A80302 09630015 FC59F74D 9EDAB3A5
     5011FDB5 4CAE0000
15. E4FAB5BC 4CDFF74D 9EDAB3A5 0000FDB5
     0058A800 4CAE

   45000028 58A84000 80068C58 C0A8917C
   C0A80302 09630015 FC59F74D 9EDAB3A5
   5011FDB5 4CAE0000

      PS:the 15 pair is failed firstly. It is not easy for me to input the datas to the email letter, so it tastes some time. Thank you.

 PS:the 15 pair is failed firstly. It is not easy for me to input the datas to the email letter, so it takes some time. Thank you.

PS:the 15th pair is failed firstly. It is not easy for me to input the datas to the email letter, so it takes some time. Thank you.

Hello,

Thank you for the uncompressed/compressed flows. I reproduced the problem, I think.
a/ the 8th packet is decompressed without error, but it doesn't match the uncompressed packet you gave me,
b/ the 15th packet fails to be decompressed.

a/ Error for 8th packet:
------------------------------ Compare ------------------------------
--------- reference ---------- ----------- new --------------
packets have different sizes (47 != 52), compare only the 47 first bytes
[0x45] [0x00] [0x00] #0x2f# [0x45] [0x00] [0x00] #0x34#
[0x3e] [0xe0] [0x40] [0x00] [0x3e] [0xe0] [0x40] [0x00]
[0x80] [0x06] [0x5d] #0xb8# [0x80] [0x06] [0x5d] #0xb3#
[0xc0] [0xa8] [0x91] [0x7c] [0xc0] [0xa8] [0x91] [0x7c]
[0x0a] [0x0a] [0x02] [0x02] [0x0a] [0x0a] [0x02] [0x02]
[0x09] [0x62] [0x20] [0xfb] [0x09] [0x62] [0x20] [0xfb]
#0x55# #0x4e# #0xf5# #0x38# #0x54# #0xef# #0x53# #0x88#
[0x00] [0x00] [0x00] [0x00] [0x00] [0x00] [0x00] [0x00]
#0x50# [0x02] #0x8f# [0xff] #0x80# [0x02] #0xff# [0xff]
#0xf3# #0xe1# [0x00] [0x00] #0x3e# #0x1a# [0x00] [0x00]
#0x6a# #0x8b# #0x88# #0xd0# #0x02# #0x04# #0x05# #0xac#
#0x5a# #0xc0# #0x31# #0x01# #0x03# #0x03#
----------------------- packets are different -----------------------

b/ Error for 15th packet:
[DEBUG] [d_tcp.c:5064 d_tcp_decode_CO()] header_crc (0x5f) != crc (0x70) on 16 bytes
[DEBUG] [d_tcp.c:794 d_tcp_decode()] return -5
[WARNING] [rohc_decomp.c:1518 d_decode_header()] failed to decompress packet (code = -5)
[DEBUG] [rohc_decomp.c:976 rohc_decompress2()] state in decompressor = 3
[WARNING] [rohc_decomp.c:1011 rohc_decompress2()] packet decompression failed with code ROHC_ERROR_PACKET_FAILED or ROHC_ERROR

I have yet to analyze the 2 problems. Maybe they are related to each others.

I create a new small test tool named 'test_interop' to ease the analysis: it tests the interoperability of the ROHC library with other implementation. The tool takes one ROHC flow and one related uncompressed flow (both generated by another ROHC implementation) as input and checks whether the ROHC library is able to decompress the ROHC flow the same way the other equipment. I'll add it to the ROHC library once I cleaned it a little bit.

Regards,
Didier

> PS:the 15th pair is failed firstly. It is not easy for me to input
> the datas to the email letter, so it takes some time. Thank you.

Maybe it would be easier if you send me the packets in the PCAP format. Tools such as tcpdump or wireshark are able to create/read them. Several test tools of the ROHC library use this format too.

See https://en.wikipedia.org/wiki/Pcap for more details.

Regards,
Didier

Thank you Didier. However, As for the TM500, We can not get the uncompressed TCP packets in the PCAP format with wireshark, which troubles me very much.

I check the input 15 pairs input datas again this morning, and I am sorry to say the 8th ROHC packet is written wrongly because of my overlook and carelessness, the right compressed tcp packet data is :

8. E3FD060E 0006C0A8 917C0A0A 02020962
    20FB0600 803EE030 02000254 EF5388FF
    FF3E1A06 A8B88D05 AC01

can you see it again?

Regards,
cxs

Hello,

The ROHC library now decompresses the 8th packet fine. There is still a problem with the 15th packet. I identified 2 problems:
 * the CRC of co_common, seq_X and rnd_X packets must be performed
    on the uncompressed headers, not on the compressed headers
 * the sequence number is invalid (only the lower 16 bits are correct)

I coded the fix for the CRC today. It seems to work fine. I'll continue with 2nd fix tomorrow.

Regards,
Didier

I am looking forward to your masterwork.

Are there some problems with you code?

Hello,

No problem with code. I was busy with something else in real life :)

I fixed the 2 remaining problems. Please try revision 1041. It decodes your 15-packet TCP stream fine!

Regards,
Didier

Hello,
      the revision 1041 can not downloaded successfully in http://bazaar.launchpad.net/~didier-barvaux/rohc/main/revision/1041, after several downloads, sometimes its size is about 20M, sometimes it is about 80M,and sometimes the size is about 110M, and whichever, as for the .tgz,it can not be decompressed with some error info.I do not know why,Thank you.

Regards,
CXS

Hello,

I don't know either. Launchpad is in charge of this feature. Try using bzr instead:
 $ bzr export rohc-main.tar.gz http://bazaar.launchpad.net/~didier-barvaux/rohc/main/

Regards,
Didier

Hello,
         After several tests, the revision 1041 failed each time with FileZilla in TM500. I am looking forward to the release TCP, and can you test it with FileZilla.(FlieZilla is a ftp application sofeware).

when does it come out?

thank you

Hello,

> After several tests, the revision 1041 failed each time with
> FileZilla in TM500. I am looking forward to the release TCP,
> and can you test it with FileZilla.(FlieZilla is a ftp application
> sofeware).

I tested a 4GB FTP transfer with Filezilla. I encountered a decompression error. I'll analyze the problem.

Regards,
Didier

I found a problem with scaled TCP sequence numbers. They were not correctly used by the compressor. I pushed it on master at revision 1068:
---------------------
  TCP profile: fix the compressor behavior about the scaled sequence number.

  The ROHC compressor shall not transmit the scaled sequence number to the ROHC
  decompressor if the compressor didn't transmit the unscaled sequence number to
  the decompressor enough times after a change:
   - the scaling factor (ie. the TCP payload length)
   - the scaling residue (ie. the sequence number increases in an irregular way).
---------------------

I started the test with Filezilla again. Let's see if everything works.

Didier

Thank you Didier.and I has the honour to read and study your masterpiece now.

> I started the test with Filezilla again. Let's see if everything works.

The test failed again. I detected a problem with W-LSB encoding for TCP ACK numbers. I fixed it (not pushed on public repository for the moment) and I restarted the test.

I think there is also a problem with scaled TCP ACK number (same problem that the previous one with scaled TCP sequence number). I'll fix it too.

Regards,
Didier

The 4-GB FTP transfer succeeded once, but failed at the 2nd try. I'm analyzing the problem.

Regards,
Didier

It is a good news, if you tried successfully completely, please tell me where the lib code is, then I will test it too.

Regards,
CXS

Hello,

> The 4-GB FTP transfer succeeded once, but failed at the 2nd try. I'm
> analyzing the problem.

The problem was related to scaled TCP sequence number. I fixed the problem in the main branch. Use revision 1085 or later.

> please tell me where the lib code is, then I will test it too.

In the main branch: https://code.launchpad.net/~didier-barvaux/rohc/main

Regards,
Didier

I encountered another problem while downloading the 4GB file. It looks like a problem with the ACK number again.

Didier

Is it a real problem with the ACK number ?

Hello,

> Is it a real problem with the ACK number ?

Yes, it is. It is related to the encoding of ACK numbers when the ACK flag is not set. I coded a fix, but I didn't find time to fully test it yet. Maybe today.

Regards,
Didier

Thank you.

Hello,
     Do you coded a fix related to the encoding of ACK numbers in the revision1085?

Regards,
cxs

Hello,

> Do you coded a fix related to the encoding of ACK numbers in the revision1085?

Revision 1085 fixed another problem. I have just fixed the other ACK problem in revision 1086. I also fixed several other problems related to the TCP profile:

  TCP profile shall use co_common if window changed and ACK number requires > 18 bits
  TCP profile: report ROHC_ERROR_CRC in case of CRC mismatch
  TCP profile: always transmit 32 bits of ACK number in IR state
  TCP profile: do not add sequence/ACK numbers twice in W-LSB window.
  TCP profile: do not transmit ACK number if ACK flag = 0 and ACK number = 0

Use revision 1091 or later to get all of them. Tell me how it behaves on your network.

Regards,
Didier

Re,

For your information, I encountered no problem while downloading the 4GB file twice in a row. It seems as if the library is more robust than a few days ago :)

How the last revision behaves with the LTE equipment?

Regards,
Didier

I will test it tomorrow.

However,It seems as if it can not be downloaded successfully in http://bazaar.launchpad.net/~didier-barvaux/rohc/main/revision/1091, when I click the "download tarball",do you know why?

I don't know. Launchpad is in charge of this feature. Try later or use bzr instead:
 $ bzr export rohc-main.tar.gz http://bazaar.launchpad.net/~didier-barvaux/rohc/main/

Hello,
   As for the http://bazaar.launchpad.net/~didier-barvaux/rohc/main/ you give me,it can not be downloaded successfully,too. It is not a file with .tar.gz format! so Can you give me the revision 1091 here in the mail letter?

regards,
cxs

or It is not a file with .tgz format!

> As for the http://bazaar.launchpad.net/~didier-barvaux/rohc/main/
> you give me,it can not be downloaded successfully,too. It is not a file
> with .tar.gz format! so Can you give me the revision 1091 here in the
> mail letter?

I cannot send you the file by email, it weight > 100 MB.

I have just tested to retrieve the file with bzr. It works fine.
$ cd /tmp
$ bzr export rohc-main.tar.gz http://bazaar.launchpad.net/~didier-barvaux/rohc/main/
$ ls -lh rohc-main.tar.gz
-rw-r--r-- 1 xxxx xxxx 112M 7 mai 09:09 rohc-main.tar.gz
$ file rohc-main.tar.gz
rohc-main.tar.gz: gzip compressed data, was "rohc-main.tar", last modified: Wed May 7 08:49:02 2014, max compression
$ tar xvzf rohc-main.tar.gz
$ cd rohc-main/
$ ./autogen.sh [options]
$ make all

Hello Didier,
       Toady I test the revision 1091 with our LTE network and TM500. Badly, using the Filezilla ,it can not log in the ftp server as before, I think the lib1091 failed in the TCP three way handshake, However, surprisedly,there is no 'error' level log in the tracer information.(PS: the TM500 can log in the ftp server and download ftp data when the ROHC function is closed ), can you see why? I will analyze the tracer log later.

Regards,
CXS

Hello,

If there is no error trace, it could either be a crash or a decompression failure (that is traced with warning level only). Please send me the library traces and/or the network capture of the ROHC packets. I'll analyze them.

Regards,
Didier

OK , It seems as if I can not send the error trace here,so what is your e-mail address ? I will send to your e-mail directly.

Hi,

You're right, the "answers" feature of Launchpad doesn't support attachment. You may attach your traces/pcap files to the related ticket in the bugtracker: https://bugs.launchpad.net/rohc/+bug/1301518 You'll find a link named "Add attachment" on the page.

Regards,
Didier

 Hello,
       I attach the traces file in the bugtracker: https://bugs.launchpad.net/rohc/+bug/1301518 .This attachment is the log for revision 1091 testing for TCP profile when TM500 communicates with FTP server, the TM500 cannot log in the FTP server.please search and filter the [ROHC ] tags, other items is not for 1091 log.

Regards,
CXS

can you see any questions?

I haven't found the problem yet. The logs are quite difficult to read: some information are missing (integer values replaced by "u" or packet dump in ASCII) and forward/return uncompressed/compressed packets are mixed. Cleaner logs could greatly speed up my analysis :)

Regards,
Didier

Thank you.