wireshark-dev August 2010 archive
Main Archive Page > Month Archives  > wireshark-dev archives
wireshark-dev: Re: [Wireshark-dev] "Decode As" - addin

Re: [Wireshark-dev] "Decode As" - adding payload decoding for the FLIP protocol

From: Juha Siltanen <jsiltane_at_nospam>
Date: Tue Aug 24 2010 - 15:01:19 GMT
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>

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