On Aug 19, 2010, at 12:25 AM, Juha Siltanen wrote:
> The FLIP protocol (implemented in packet-flip.c) works on top of Ethernet, having type 0x8901 and adding its own headers plus payload. The FLIP headers contain no indication of the payload type and it cannot be deduced from the contents of the capture either. I would like to give the user an option to decode the payload to the protocol of his choosing by using "Decode As". The problem is that right-clicking and choosing "Decode As" only gives link-level protocols, and I would like to decode the payload using transport-level protocols (for example RTP).
Unfortunately, the "Decode As" mechanism is not a general mechanism usable for all protocol handoffs. For one thing, it's oriented towards protocols that have some field that could be used as a protocol selector; as FLIP has no such field (as per "The FLIP headers contain no indication of the payload type"), it's not appropriate for this case. (I.e., "Decode As" means "decode XXX as YYY", where XXX is a particular value for a particular protocol field, but there's no XXX available in this case.)
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.