On Feb 25, 2009, at 1:18 AM, Akshitij Malik wrote:
There is no Protocol ID field in the L2TPv3 Header that identifies
the encapsulated protocol.
Somehow, using preferences one specifies how to interpret the L2TPv3
payload.
So it is not possible to register a protocol based on some header-
field value of L2TPv3 Header.
There's no requirement that the field used for a dissector table be a
field in the packet, so that, by itself, doesn't prevent you from
having a dissector table for the L2TPv3 pseudowire type.
This does bring up another issue. Currently, the only mechanism we
have for specifying the pseudowire type for an L2TPv3 session is a
global preference, but a capture might have multiple L2TPv3 sessions
which might be using different pseudowire types, and if we capture the
session setup we might see a Pseudowire Type AVP that specifies the
pseudowire type.
This might be done best with:
1) a mechanism that identifies L2TP flows by the endpoint addresses
and the session ID;
2) a mechanism to attach a pseudowire type to a flow;
3) a mechanism by which you can specify the pseudowire type for a
flow in the GUI (and perhaps via a command-line option for TShark);
4) the L2TPv3 dissector setting the pseudowire type for a flow if it
sees a Pseudowire Type AVP.
Ideally, we'd want:
1) a mechanism, subsuming the current conversation and circuit
mechanism, for identifying flows at multiple protocol layers;
2) a mechanism for attaching arbitrary attributes to a flow and
fetching the attributes for a flow;
3) a mechanism for a dissector to register user-settable per-flow
attributes, which could be edited through the GUI (and possibly set
via a command-line option);
which could be used by other dissectors.