|Main Archive Page > Month Archives > wireshark-dev archives|
2010/8/21 Guy Harris <firstname.lastname@example.org>
> 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
> 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 <email@example.com>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
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
Sent via: Wireshark-dev mailing list <firstname.lastname@example.org>