Re: "Decode As" - adding payload decoding for the FLIP protocol

[Juha Siltanen <jsiltane () gmail com>]

2010/8/21 Guy Harris <guy () alum mit edu>

> On Aug 19, 2010, at 1:00 AM, Anders Broman wrote:
>
> > > Currently, the best way to handle this is probably to have a preference
> for FLIP that specifies the payload
> > > protocol; that preference would be an enum preference, listing the
> possible protocols.  The dissectors for the
> > > protocols in question would
> > >
> > >      1) have to *NOT* assume that they're running atop, for example, a
> transport-layer protocol such as TCP or
> > > UDP running in turn over IP (for example, they can't assume that a
> network-layer address is available)
> > > and
> > >
> > >      2) be registered with a name, so that the FLIP dissector can fetch
> a handle for them.
> > For the user DLT I think it is possible to specify the handoff protocol
> by name in the UAT table.
> > The caveat is of course that the handoff protocol has to be registered by
> name.
>
> Exactly - "The dissectors for the protocols in question would ... [have to
> be] be registered with a name, so that the FLIP dissector can fetch a handle
> for them."
>
> However, this is different from the user DLT, where you have a mapping
> between user DLT values and dissectors; in this case, there's no protocol
> type field from which to map, so the "map" has only one row and one column
> in it, meaning it has only one value in it, namely the dissector to use.
>
> (As for item 1), that also applies in the user DLT case - a dissector that
> fails if, for example, it can't find a source or destination IP address for
> the packet, as supplied by the dissector calling it, isn't going to work
> very well as a user DLT dissector, as there's no IP dissector above it in
> the stack, just as it won't work well as a FLIP payload dissector.)
> ___________________________________________________________________________
> 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

My first approach was to utilize the heuristic dissectors, "knowing" that
the payload would be RTP/RTCP. This approach has some problems: the
heuristic dissectors have to 'opt-in' i.e. call heur_dissector_add for FLIP,
and I also had to modify heuristics code that assumes the lower-level
protocol to be IP (checking out port values).

The second approach was to use the preferences (as advised by you guys).
There are three options implemented using radio buttons: 1) no decoding, 2)
heuristic decoding to RTP/RTP (where the heuristic logic is actually in
packet-flip.c) and finally 3) decoding using a user-specified dissector.

The third point is giving me a bit of trouble. The simplest approach would
be having a string preference where the user can input the desired protocol,
but I rather like the UAT functionality  that checks that the protocol is
actually available before closing the dialog (UAT_FLD_PROTO). No such thing
for a preference? Then again, constructing an UAT just to get one string in
seems like overkill, so I decided to try something more advanced and offer a
possibility to map flow IDs to dissectors (HEX to PROTO). When I write to
the UAT HEX field a value that is sufficiently large (at least 0x80000000) I
get 0x7fffffff displayed. Is there a range limitation for
UAT_FLD_HEX/UAT_HEX_CB_DEF?

___________________________________________________________________________
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