Re: display filtering + how to analyze some TCP packets

[Guy Harris <guy () alum mit edu>]

On Oct 26, 2011, at 3:14 AM, Teto wrote:

> On Tue, Oct 25, 2011 at 6:37 PM, Guy Harris <guy () alum mit edu> wrote:
>
> > If it's a predefined port for TCP, do the same sort of thing, but using "tcp.port" and the predefined TCP port 
> > number and handle for the dissector for your protocol when it runs over TCP.
>
> In fact there is one predefined port for udp and tcp but they can be
> changed to some arbitrary port.

Then you could either use a heuristic dissector or make the port numbers a preference, with the default values being 
the predefined ports.  See the HTTP dissector for an example of how that's done - it supports port ranges, so more than 
one port can be specified, e.g. you can have a comma-separated list with the default port and an additional port.

> > If it's not a predefined port, you'd have to, well, analyze the first bytes to know if it matches your protocol.
>
> Right now I analyze the first 2 bytes to check if it's equal to 0x0002

That's somewhat of a weak check, so if you use it at all, you should have a preference to disable it.  (We have a 
similar weak heuristic for RTP, and disable it by default.)

However, if that's the best heuristic you can use, a port preference might be better, given that it has predefined 
ports.

> but I am not sure it's the right check (protocol specs are
> unavailable).

So I assume your dissector is being developed by reverse-engineering the protocol (which I'm guessing is

        http://www.cisco.com/en/US/prod/switches/ps5718/ps10195/white_paper_c11-514539.html

and which I assume is somehow Shinier and Better than other protocols such as BACnet, with "Better" meaning something 
other than "sells more Cisco equipment" :-)).

> If 2 dissectors match the bytes, what may happen ?

Whichever heuristic dissector happens to have been registered first wins.  There is no supported mechanism by which 
dissectors can control the order in which they register.

> > That means making your dissector a heuristic dissector, which:
> >        returns a gboolean value - TRUE if it matches, FALSE if it doesn't;
> >        as its first action, before doing *anything* to the protocol tree or the columns, checks whether the first 
> > bytes look as if the packet is for your protocol or not;
>
> Ok it works \o/  Once I recognize the packet matches my protocol,
> shoulddissect_energywise_tcp_heur  further analyze the packet

Yes.

> or immediately returns true and wireshark would give the packet to some
> other dissector ?

No, if it were to immediately return TRUE, Wireshark would (incorrectly) assume your dissector had dissected the packet.

> Btw, I Had an assert DISSECTOR_ASSERT_NOT_REACHED(), hopefully I
> looked at the code before asking you and the comment next to assert
> was "/* This part is not implemented yet */". Is it not possible to do
> a  DISSECTOR_ASSERT_NOT_REACHED("This part is not implemented yet"). ?

No - DISSECTOR_ASSERT_NOT_REACHED() is intended to be used when it should *never ever* be possible to reach that 
location, even when the dissector is completely implemented.

What you should do in cases where you haven't yet implemented something is to just put something into the protocol tree 
indicating that.
___________________________________________________________________________
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