The uncompress method is mentioned in several places in documentation. I know what it's suppose to return, but I'm not sure about its parameters. Its code comments state that it "uncompresses a zlib compressed packet inside a message of tvb at offset with length comprlen." I figured the "tvb" is the buffer passed unto the dissector and the "offset" is the pointer at which the method is to begin uncompressing data, but I don't know what the length "comprlen" is in relation to the data or the process. Is it the current reported length of the buffer to be uncompressed? Is it the expected length of the uncompressed buffer after decompression? asked 20 Apr '16, 16:59  coloncm |
One Answer:
You have received a tvb, and from your protocol know the offset as well as the length of the compressed data. How you know these parts really depends on the protocol at hand. Offset is usually a specific field in the PDU. Length can be also in a field in the PDU or follows from the encapsulating protocol, eg. UDP payload length. So tvb_reported_length_remaining() or tvb_captured_length_remaining() can be of service here. answered 21 Apr '16, 01:20  Jaap ♦ |
Thanks, @Jaap. I am using tvb_reported_length_remaining() now, but it's not giving off 100% decompression of all PDUs. I was actually wondering if I am suppose to be using the length value in the first bytes of the PDU as you mentioned. If I do, though, wouldn't I risk decompressing at an erroneous inflation (which might increase errors in decompression)?
It sounds like the method is flexible enough that the given length may not even be necessary. By that I mean, the method could go in and get its own "comprlen" value from the passed tvbuff_t object, instead. This is the confusing part for me.
Perhaps, I should rephrase my follow up question. Which of the values you mentioned is the recommended or most widely used value to use for this method: the PDU/payload length value, the tvb_reported_length_remaining() value or the tvb_captured_length_remaining() value?
It's up to the dissector calling the method to determine the length of the compressed data in the tvb.
The length of the compressed data may not be all of the remaining tvb, hopefully the protocol using zlib compression has added a length or some other delimiter so that a normal recipient can decompress the data, and the dissector can use that to pass into the uncompress function.
If there are no such explicit length indicators all you can do is pass in
tvb_reported_length_remaining()as this is what "should" be in the packet.Using the captured length in general in any dissector isn't a good idea as your dissector won't be reporting malformed packets due to capture length limitations, and the decompressor will fail if the capture length has been reduced as there will be missing compressed data.
Clear as mud! Thanks, @grahamb.