Stefano Pettini wrote:
I have a question about a relationship between some fields and protocols.
I have protocol A (A over UDP) that can transport protocol B (B over A,
of course) and protocol C (C over A). Protocol A has extensions and
variable fields, identified by a number.
There are extensions with a number within a known interval that are
related to A, but there are also additional extensions with a number
within another known interval related to the upper layer protocol (B, C
or other protocols).
For example, in protocol A, the extension numbered 64 contains data
related to protocol B, if A transports B, or to protocol C, if A
tranports C.
There's no way to understand the protocol of A's payload. This should be
done manually by the user, using the "decode as ..." window.
Currently, that can't be done without modifying the "Decode As..." code
- the only fields that the "Decode As" window supports are:
the Ethernet type;
the IP protocol;
TCP ports;
UDP ports;
SCTP PPIs.
That only affects the *immediate* handoff for those fields - it can
affect what the UDP dissector will call for a particular port number,
but it cannot affect what the dissector called by the UDP dissector will
call.
There's also a mechanism, for DCE RPC, to specify the DCE RPC-based
protocol to use for a combination of TCP source and destination ports,
context ID and, for DCE RPC over SMB named pipes, the SMB FID fo the
pipe being used.
To use "Decode As", you'd need to add some mechanism that would indicate
to the dissector for protocol A that, based on something, such as the
UDP port number, particular packets should be passed to protocol B or
protocol C.
Another possiblity, *if*, within any given capture, protocol A will
always hand off to a particular protocol - i.e., within any given
capture, all protocol A packets are also protocol B packets or protocol
C packets, no capture will have both protocol B or C packets - you could
add a preference to protocol A indicating whether it should hand off to
protocol B or C.
Where should I write the code to dissect those extensions?
If I add their dissector in A, how can I know which is the upper layer
protocol choosen by the user?
If there's a protocol that transports another protocol, the dissector
for the first protocol is responsible for calling the dissector for the
other protocol; in most cases, it's capable of finding out what that
dissector is (and, if we were to add a "conversation_get_dissector()"
function, that'd handle the remaining case).
So dissector A would know whether it'd be calling dissector B or C, and
should dissect the options based on that.