On Sun, Mar 17, 2002 at 08:38:07PM -0500, Aamer Akhter wrote:
> We can get it to mostly work for Ethernet Over Mpls (except for the poor
> packets whose destination starts of 4 or 6), but there is no guarentee that
> it's that kind of packet even the above is finger crossing at best, and is no
> answer for frame-relay or ATM over mpls.
>
> I am thinking that leaving the above change in is better than nothing
The above change is better than nothing but worse than declaring
static dissector_handle_t eth_dissector;
at the top of "packet-mpls.c", doing
eth_dissector = find_dissector("eth");
in "proto_reg_handoff_mpls()", and doing
if (ipvers == 6) {
call_dissector(ipv6_handle, next_tvb, pinfo, tree);
} else if (ipvers == 4 ){
call_dissector(ipv4_handle, next_tvb, pinfo, tree);
} else {
call_dissector(eth_handle, next_tvb, pinfo, tree);
}
(why search a table on *every call* when you can do it only once?).
> and modifying the 'Decode as' user selectable option to include 'MPLS encaped'
> along with 'link', 'network' and 'transport'.
If you want to decode something as something, you need to have a way to
specify what the first "something" is.
For link-layer "Decode as", the "something" is specified by the Ethernet
type field in the packet.
For network-layer "Decode as", the "something" is specified by the IP
protocol type field in the packet.
For transport-layer "Decode as", the "something" can be specified by the
source TCP/UDP port number, the destination TCP/UDP port number, or both
in the packet.
What would specify that "something" for MPLS?
If the intent is to have *all* MPLS traffic be decoded as a particular
protocol, that'd be a preference item for the MPLS dissector.
If the intent is to have *some* MPLS traffic be decoded as a particular
protocol, that'd be the "something" in question.