Wireshark-dev: Re: [Wireshark-dev] Possible bug with check_col?

From: Brian Vandenberg <phantal@xxxxxxxxx>
Date: Thu, 28 Sep 2006 12:55:33 -0600
Ulf,

Certain of it. My protocol tree gets created and added below the http tree. In addition, if I remove my plugin from the plugins folder and run wireshark and open the pcap file I'm using for testing I see the exact same behavior: the http response packets still show up as TLSv1 packets in the packet list, but the http tree is created.

When I trace execution of my dissector it gets to the check_col lines and skips over both of them every time. It seems to only be response packets, but I could be wrong on that. I just did a test to find out what's up, and it looks like pinfo->cinfo->writable == FALSE when I encounter these packets, and the HTTP dissector as well as mine can't set the column info for those columns, which is why check_col is always returning false for those particular packets.

One thing I've noticed that's rather interesting, each time I run into this problem the http dissector is producing a new proto tree twice after the SSL dissector has decrypted the payload http ends up dissecting. The new trees contain the same data both times.

I'm also finding that the SSL dissector isn't always decrypting everything. I'll be looking into that more, though.

-Brian

Ulf Lamping wrote:
Brian Vandenberg wrote:
I'm writing a dissector that relies on the http dissector. The server's I'll be monitoring use ssl, so there's a requirement to use the ssl dissector to decrypt the packets and hand them off to the http dissector.

Requests & responses are both treated properly during dissection, so that isn't an issue. That is, with one caveat: for some reason, the following code never causes the columns to be changed in my dissector, and it also seems to fail to do the same thing in the http dissector:

if (check_col (pinfo->cinfo, COL_PROTOCOL))
  col_set_str (pinfo->cinfo, COL_PROTOCOL, "ABBRV");

if (check_col (pinfo->cinfo, COL_INFO))
  col_set_str (pinfo->cinfo, COL_INFO, "Some info");

  The columns continue to say:

Protocol: TLSv1
Info: [SSL segment of a reassembled PDU]

So, three questions: has anyone else seen this before, is this a bug, and is there a workaround?

Are you sure your dissector get's called at all?

It looks like an SSL reassembling is going on, without a data chunk for the upper layer protocol.

Regards, ULFL