How to make wireshark parse ethernet frame over MPLS as no CW?

Question

I have an Ethernet over MPLS over UDP packet. Wireshark wrongly parses it as it contains CW. Below is the pcap file. Since the UDP port is 51234 instead of 6635 as defined, I use following LUA script to make wireshark to parse the UDP payload as MPLS

mplsoudp_proto = Proto("mplsoudp","Mpls over UDP")
local dis_mpls = Dissector.get("mpls")
function mplsoudp_proto.dissector(buffer,pinfo,tree)
    dis_mpls:call(buffer,pinfo,tree)
end
udp_table = DissectorTable.get("udp.port")
udp_table:add(51234,mplsoudp_proto)
udp_table:add(6635,mplsoudp_proto)

https://onedrive.live.com/redir?resid=DCB291F7224C3741!182&authkey=!AAa_6r-uzbzrWn0&ithint=file%2cpcap

Wireshark parses it as CW is present although it actually doesn't.

alt text

Tried disable "Ethernet PW (with CW)"/"Ethernet PW(CW heuristic)". The MPLS payload is simply shown as Data. Is there any way to make Wireshark parse this packet as no CW is present?

alt text

Thanks

Answer 1

0

In your first step, you've made a complex equivalent of "Decode as", telling the UDP dissector that it should invoke the mpls dissector also for udp.dstport == 51234.

By disabling the heuristic dissector Ethernet PW (CW heuristic), you've only stolen the MPLS dissector the tool allowing it to find out how to handle the payload.

So to compensate, you must use another "decode as" (or its equivalent in Lua), and similarly as if you would be configuring an MPLS switch/router, you have to say that packets with mpls.label == 18 (in your particular case) shall be dissected as Ethernet PW (no CW).

I don't think there is a reason to do this using Lua unless you want to use Lua to provide a better heuristic, allowing you to choose between Ethernet PW (no CW) and Ethernet PW (with CW) yourself on the fly. However if you can put together a heuristic more accurate than the existing one, I'm sure gents would happily integrate it.

I also don't think there is a need to create a special protocol name (MPLSoUDP) when you the only thing you actually needed to do was

local dis_mpls = Dissector.get("mpls")
local udp_table = DissectorTable.get("udp.port")
udp_table:add(51234,dis_mpls)

and then, if you insist on use of Lua to create static "Decode as" equivalents,

local dis_eth = Dissector.get("eth")
local mpls_table = DissectorTable.get("mpls.label")
mpls_table:add(18,dis_eth)

answered 04 Feb '16, 23:17

sindy
6.0k●4●8●51
accept rate: 24%

edited 04 Feb '16, 23:21

Hi Sindy,

Thanks for the reply. To make life easier, I don't want to use Lua when possible. :) The challenge I have it not how to make wireshark to parse UDP payload as MPLS. What I have been trying to figure out is how to parse the MPLS payload as ethernet with CW.

Looks like the packet matches some pattern such that Wireshark believes the bytes followed the MPLS header is a CW instead of the dst MAC. Unfortunately, this is not the case. Is there any way to correct it?

Matching label value in Lua doesn't seems feasible as I have lots of packets like this but having different MPLS label values.

Thanks,

(05 Feb '16, 11:15) yacare

What I have been trying to figure out is how to parse the MPLS payload as ethernet with CW ... as I have lots of packets like this but having different MPLS label values.

I think you wanted to write "without CW", but that's not the essence. The essence is that the same way like the server-side TCP port distinguishes between different services using TCP transport, the MPLS label distinguishes between virtual paths, each potentially carrying a different protocol.

So the requirement above is quite similar to "I want to be able to tell Wireshark to decode all TCP packets as HTTP because I have lots of HTTP packets using various TCP ports at server side". Both make sense in particular context but it is not a typical application case.

You may want to file a "nice to have" category bug at Wireshark bugzilla, asking for a generic mechanism allowing this; some kind of reserved index value (such as other) for the dissector tables might be a useful way allowing you to set a default dissector (using Decode as... or Lua dissectortable:add) which could still be overridden by the individual ones.

Until someone implements this or something alike, you'll have to run dissectortable:add in a cycle in Lua to fill the relevant dissector table with pointers to the same dissector for all possible index values. I admit that for a 20-bit MPLS label, doing so may take some time and use some memory.

(05 Feb '16, 12:52) sindy

Thanks. It is good to know there is no easy solution here. I guess this is more because of the way MPLS header is designed. There is no indication on what the payload would be. Applications have to take a guess. This causes lots of issues like load balancing etc. :(

(05 Feb '16, 13:33) yacare

Applications have to take a guess.

I would disagree - it is only an issue for monitoring applications, such as Wireshark. The real applications using MPLS don't need to guess because they know. The sending application (if we may call an edge router an application) knows what label to assign to the traffic, the receiving application knows what kind of payload it expects, and the transit elements between these two endpoints don't care, because they just choose the interface to which to forward a packet up to the value of the label and it is irrelevant for them what the payload is. So any kind of explicit payload type identifier included into each packet would be just a waste of bandwidth.

(05 Feb '16, 13:57) sindy

It is not only for monitoring applications. For better load balancing purpose, the routers in the middle may want to know more about the MPLS payload. For instance, rfc6790 has to add another MPLS label in order to address this.

(08 Feb '16, 07:25) yacare

I'm not sure whether it is still a Wireshark-related discussion, but when reading the RFC 6790's section "Motivation", I can see it points in the same direction I've suggested above - it should not be the transit LSR's job to analyze each packet's contents, as asking it to do so contradicts the original idea of MPLS as a means of simplification of the routing process in the transit network.

Yes, nowadays MPLS is mainly used for other reasons than the mapping of payload protocols' native addresses to simple routing labels, yet still the instruction what a transit LSR should do with a packet with a given label gets to it "out-of-band" - i.e. using either manual configuration or some configuration management communication, but definitely not inside each individual traffic packet. So even if the transit LSR has to analyse the packet contents in order to choose between several possible routes, the contents encapsulation scheme is invariant for any given label, and so the LSR should not depend on heuristic when handling packets but should get the information about the encapsulation scheme the same way it has got the information about its local route set for that label.

(08 Feb '16, 13:22) sindy

showing 5 of 6 show 1 more comments