2010/7/19 Stig Bjørlykke <stig@xxxxxxxxxxxxx>:
> On Mon, Jul 19, 2010 at 4:39 PM, Tarjei Knapstad
> <tarjei.knapstad@xxxxxxxxx> wrote:
>> However, my dissector (or heurisic dissector) never gets called in any
>> of these cases.
>
> What happens if you disable the http dissector?
Disabling the HTTP dissector didn't work. I stepped through the code,
and it seems like this is what happens:
- The TCP dissector calls dissector_try_port() on port 80 which is the
low port (packet-tcp.c:2858)
- dissector_try_port_new() does a lookup in the dissector table and
(presumably) finds the HTTP dissector
- call_dissector_work() determines that the protocol isn't enabled and returns 0
- dissector_try_port_new() in turn returns false. the documentation
here says (packet.c:913):
/* If the packet was rejected, we return FALSE, so that
* other dissectors might have a chance to dissect this
* packet, otherwise we return TRUE.
*/
...but I don't see where this is supposed to happen. The disabled
protocol does not get removed from the subdissector table, and the TCP
dissector makes no further attempts at calling subdissectors if the
first call fails. Should this be considered a bug? I even tried
calling dissector_reset("tcp.port", 80); before adding my own
dissector in the handoff routine (and made sure the handoff for my
protocol is called after all the others, see my earlier post on that
issue: http://www.wireshark.org/lists/wireshark-dev/201007/msg00142.html)
> Or remove port 80 from the http preferences?
>
This didn't work either. The dissector_add call from my dissector
handoff function goes through fine (stepped through this in gdb
again), but when the TCP dissector performs a lookup in the
subdissector table later, a null pointer is returned (I verified that
the subdissector table where my dissector gets added and the one where
lookup is performed is the same). Why this lookup fails is still a
mystery to me, looking into it now.
Regards,
Tarjei