Prior to upgrading to v2.2.0-0-g5368c50 from master-2.2, wireshark would decode the embedded ethernet packets that are encapsulated inside 2 layers of MPLS. Now wireshark, simply shows the embedded ethernet frames as "Data". How can I configure wireshark to decode this? asked 28 Sep '16, 09:54  yohio showing 5 of 7 show 2 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Hard to say without the capture file. There are several types of encapsulation of the payload into MPLS which cannot be unambiguously recognized just by the data, so all the time there were complaints like "why Wireshark is dissecting my MPLS packets as XXX when they are YYY". So my guess is that in 2.2.0, the auto-detection has been disabled completely, or just the detection algorithm has been modified.
To know more, you'd have to publish the file, login-free, at Cloudshark or some plain file sharing service and edit your Question with a link to it.
If I remember correctly this functionality was changed at some point, requiring you to use "Decode As" on the packets you want decoded. Not sure though.
I uploaded a snippet from the capture to cloudshark here: https://www.cloudshark.org/captures/6da65676be67
The MPLS data is clearly encapsulated IP over ethernet 2. I would like wireshark to automatically decode this.
To be more clear, the MPLS data in the above capture is ethernet IP - containing GTP (UDP port 2152) which in turn encapsulates TCP traffic
As already said - currently, you have to use
Decode asto tell Wireshark to dissect the MPLS payload asEthernet PW (no CW)for each top level MPLS label (two in your snippet, one per direction).This way you in fact give Wireshark the information about MPLS border router configuration for that label.
There are so many possible MPLS payloads that no heuristic tried so far was 100% successful in recognizing them by contents, resulting in confusion as described above. Even the detection whether a control word (CW) is used or not in the pseudowire (PW) encapsulation was not always reliable.
BTW, the use of test MAC addresses with many
00in them, like one of yours here, is one of the reasons of the heuristic failure, because zero bits at these positions are valid for many types of payload so more than one type meets the criteria of the heuristic. So maybe (I'm not the author of the MPLS dissector) the current heuristic just says "I don't know what it is as there is more than one possibility" where the old has returned the first successful match.Clue #1: If offset 12 of the MPLS data contains the value 0x800 then there is a 99% chance that the MPLS data is encapsulated IP over ethernet. I may undertake changing the MPLS decoder myself to do this based upon a new property.
First, 1% of false positives would still be way too high.
Second, if your Ethernet frame would be encapsulated into MPLS as Ethernet pseudo-wire with control word, and the source MAC address of the payload Ethernet frame would contain
08:00in the middle of the source MAC address (see first example below), then using your Clue #1 would end up dissecting your packet the way shown in the second example below.Not to be misunderstood: I'd also love to see Wireshark auto-detect everything, but false positives are much more harmful to protocol analysis than false negatives.
So the second example is still quite good as you can see that something went wrong, but in other cases such frame could be dissected completely wrong but without any errors reported.
Frame 1: 1505 bytes on wire (12040 bits), 1505 bytes captured (12040 bits) Ethernet II, Src: Nokia_e5:94:93 (38:52:1a:e5:94:93), Dst: Nokia_90:8e:04 (8c:90:d3:90:8e:04) 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10 MultiProtocol Label Switching Header, Label: 262118, Exp: 0, S: 0, TTL: 255 MultiProtocol Label Switching Header, Label: 262134, Exp: 0, S: 1, TTL: 255 PW Ethernet Control Word Ethernet II, Src: 18:80:08:00:97:d8 (18:80:08:00:97:d8), Dst: ae:00:00:00:00:01 (ae:00:00:00:00:01) Destination: ae:00:00:00:00:01 (ae:00:00:00:00:01) Source: 18:80:08:00:97:d8 (18:80:08:00:97:d8) Type: IPv4 (0x0800) Trailer: 926168 Internet Protocol Version 4, Src: 10.155.182.18, Dst: 10.155.182.251 User Datagram Protocol, Src Port: 2152, Dst Port: 2152 GPRS Tunneling Protocol Internet Protocol Version 4, Src: 208.4.120.128, Dst: 64.34.170.24 Transmission Control Protocol, Src Port: 46608, Dst Port: 80, Seq: 1, Ack: 1, Len: 1370Frame 1: 1505 bytes on wire (12040 bits), 1505 bytes captured (12040 bits) Ethernet II, Src: Nokia_e5:94:93 (38:52:1a:e5:94:93), Dst: Nokia_90:8e:04 (8c:90:d3:90:8e:04) 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10 MultiProtocol Label Switching Header, Label: 262118, Exp: 0, S: 0, TTL: 255 MultiProtocol Label Switching Header, Label: 262134, Exp: 0, S: 1, TTL: 255 Ethernet II, Src: 00:00:00_01:18:80 (00:00:00:01:18:80), Dst: 00:00:00_00:ae:00 (00:00:00:00:ae:00) Destination: 00:00:00_00:ae:00 (00:00:00:00:ae:00) Source: 00:00:00_01:18:80 (00:00:00:01:18:80) Type: IPv4 (0x0800) Internet Protocol Version 4 1001 .... = Version: 9 [Expert Info (Error/Protocol): Bogus IPv4 version]