Comment 3 for bug 1495527

The problem is the value of the total length field in the IPv4 header of the 4th packet.
In the source.pcap from git it has the value 72, which is wrong, because
the packet is 60 bytes in size. The (my) compressor don't check this, but
it computes the crc3/7 header checksum over it.
The total length is not transmitted, because the decompressor
computes it. And here is the problem. The decompressor
computes a different value, because it uses the correct value 60 for the total length
field in the IPv4 header. And this results into a different crc3/crc7 value
for the header checksum. Then the decompressor detects and notifies a
decompression error, because the crc value does not match.
After I corrected it, everything works fine, because the IP checksum is
also correct now, for what reason ever.

Therefore it is important, that the header values, which are not
explicit transmitted, but computed by the decompressor, have a
correct (the same value as computed by the decompressor) to
avoid crc failures for non IR or IR-DYN packets. In IR/IR-DYN packets
the crc checksum is not computed over the uncompressed IP packet, but over
the IR/IR-DYN packet itself.

Best,
Klaus Warnke