This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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's gravatar image

yohio
6112
accept rate: 0%

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.

(28 Sep '16, 10:46) sindy

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.

(28 Sep '16, 15:05) Jasper ♦♦

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.

(30 Sep '16, 08:47) yohio

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

(30 Sep '16, 09:06) yohio

As already said - currently, you have to use Decode as to tell Wireshark to dissect the MPLS payload as Ethernet 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 00 in 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.

(30 Sep '16, 09:08) sindy

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.

(03 Oct '16, 15:41) yohio

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:00 in 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: 1370

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 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]

(03 Oct '16, 23:08) sindy
showing 5 of 7 show 2 more comments
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×25

question asked: 28 Sep '16, 09:54

question was seen: 5,143 times

last updated: 03 Oct '16, 23:08

p​o​w​e​r​e​d by O​S​Q​A