This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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?

tvbuff_t tvb_uncompress(tvbuff_t tvb, const int offset, int comprlen)

asked 20 Apr '16, 16:59

coloncm's gravatar image

coloncm
7681115
accept rate: 66%


Uncompresses a zlib compressed packet inside a tvbuff at offset with length comprlen.

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.

permanent link

answered 21 Apr '16, 01:20

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

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.

(21 Apr '16, 04:36) coloncm

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?

(21 Apr '16, 17:55) coloncm
1

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.

(22 Apr '16, 00:39) grahamb ♦

Clear as mud! Thanks, @grahamb.

(25 Apr '16, 04:48) coloncm
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×637
×8
×3

question asked: 20 Apr '16, 16:59

question was seen: 1,409 times

last updated: 25 Apr '16, 04:48

p​o​w​e​r​e​d by O​S​Q​A