Re: Correct way of adding a HTTP subdissector on port 80 with no content type?

[Tarjei Knapstad <tarjei.knapstad () gmail com>]

> > 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.

OK, I tracked down the cause of this too now. When the application is
started, the HTTP dissector is added to port 80, then my dissector
gets added to port 80 and finally the HTTP dissector removes itself
from port 80 when applying the preferences. The dissector_delete()
function however ignores the handle passed in as an argument and
simply deletes whatever dissector it finds matching the pattern (port
80), so instead of removing itself it removes my dissector from the
subdissector table. This is documented, but I don't quite understand
the reason (including the handle as a variable for consistency
certainly made things more confusing :) )


/* Delete the entry for a dissector in a uint dissector table
   with a particular pattern. */

/* NOTE: this doesn't use the dissector call variable. It is included to */
/*      be consistant with the dissector_add and more importantly to be used */
/*      if the technique of adding a temporary dissector is implemented.  */
/*      If temporary dissectors are deleted, then the original dissector must */
/*      be available. */
void
dissector_delete(const char *name, const guint32 pattern,
        dissector_handle_t handle _U_)


This means that it's not possible to disable the HTTP protocol for
port 80 in the preferences and allow some other dissector to handle
that traffic. I'm attaching a proposed patch, but I'm guessing it may
very well carry side-effects which I don't quite understand. A
possible solution might be for my dissector to also have a port list
preference, but I'm not sure if there's any guarantee that the
preferences for my dissector will be applied after the preferences for
the HTTP dissector (if not, I'm back to square one).

Regards,
Tarjei

Attachment: packet-dissector_delete.patch
Description:

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe