Wireshark-dev: Re: [Wireshark-dev] "Decode As" - adding payload decoding for the FLIP protocol
2010/8/21 Guy Harris
<guy@xxxxxxxxxxxx>
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.)
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?
