Marc Petit-Huguenin wrote:
I need an advice for a special case I'll have to implement. The regular
packets to be dissected does not contains enough information to select
the right dissector, but there is at the beginning of the exchange some
packets that permit to choose this dissector. Let me explain this with
an example:
IP/port 1 IP/port 2
| |
1 |------------------>|
2 |<------------------|
| |
3 |------------------>|
4 |<------------------|
5 |------------------>|
6 |<------------------|
| |
The packets 1 and 2 contains enough information to select the dissector
that will be used to dissect packets 1 to 6, but packets 3 to 6 does
not. Is there a way to express that after packet 2, all the subsequent
packets on this specific pair of IP/port will always use the same
dissector? Obviously, if the packets 1 and 2 are missing, then the
dissector cannot be selected. Packets can be carried by UDP or TCP (or
SCTP or DCCP...)
Several dissectors do this, frequently via the conversation API (see
doc/README.request_response_tracking for some info).
One example I am somewhat familiar with (that does not use the
conversation API) is epan/dissectors/packet-sccp.c: the SSN (which
generally determines the next protocol) is only present in the first 2
messages (CR and CC) in a Class-2 exchange so the SCCP dissector stores
some data (see the "assoc" variable and the routines for setting/getting
it) that includes the SSN. Then when it sees a later packet (DT1 or
DT2) it can pull the data from 'assoc' to find the SSN and thus the next
protocol.
HTH,
-J
