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

Wireshark converting IPv4 to IPv6

0

This is one of the strangest problems I have ever encountered. I am troubleshooting problems with an MPLS pseudowire going through a PROCERA (dpi) device, which is blocking authentication to the page ( loading the page, works fine, when you log in it times out ). When I take a PCAP on the WS server DOWNSTREAM from the PROCERA I have set up all looks normal. You can see the bidirectional communication and negotiation of protocols. However, when I pull the PCAP off the server and reopen it in WS, it looks very strange with only one-way communication and a bunch of IPv6 that seemingly came from nowhere. What the heck is going on?

asked 07 Nov '14, 11:25

multipl3x's gravatar image

multipl3x
11114
accept rate: 0%


2 Answers:

1

Looks quite strange indeed, but PNGs can only tell you so much. I suspect that the MPLS somehow mangles the content of the frame, especially since the destination address starting with 5c8a is invalid (valid range is 0x2000-0x3fff for unicast IPv6). Also, this is not a valid Hop-by-hop option header, so my guess is that some protocol identification fields are plain wrong.

I would compare frames byte wise to check if the content on the bad side matches what you see on the good side, and where the differences are. Not much more to tell you without an actual capture.

answered 07 Nov '14, 11:50

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

here are the actual caps, if that helps. Unfortunately it is hard to compare anything as as soon as they are saved they change to IPv6. Thanks for looking

(07 Nov '14, 12:00) multipl3x

All your traces contain broken frames (there is really no bad or good here, it's all bad), and none of the IPv4 packets are part of complete TCP conversations - there is a lot of expected IPv4 stuff missing (e.g. all answers to the GET requests), but all that is in the broken frames (decoded as IPv6, but you can see the HTTP content in the packet bytes).

Wireshark doesn't convert anything, it just decodes what it sees in the frames - and your frames are not making any sense. It looks to me that the MPLS transport mangles them somehow.

(07 Nov '14, 12:19) Jasper ♦♦

I don't understand why MPLS would do this. Another added oddity is that when I download and install wireshark 1.6.7 on windows, which is the same version as the WS server I used to capture this, (ubuntu does not have an updated version, apparently), they open fine. This can be illustrated here. Seems we have the trouble in Version 1.12.1

(07 Nov '14, 13:17) multipl3x

Seems we have the trouble in Version 1.12.1

Please file a bug, then, at the Wireshark Bugzilla and, if possible, attach a capture file that demonstrates the problem.

(07 Nov '14, 15:24) Guy Harris ♦♦

For a bug report I suggest referencing line 630 of file packet-mpls.c. The heuristics for next-protocol detection aren't great (nor are they great in the standards for this as far as I can tell). The writer was clearly aware of this as per comments at line 641.

(07 Nov '14, 16:12) Quadratic

0

I believe the cause starts at line 630 of file epan/dissectors/packet-mpls.c of Wireshark 1.12. When the CW header isn't there Wireshark uses "first nibble" logic to figure out the next protocol, and from the notes it isn't quite finished or perfect. Literally, it decodes this as IPv6 because the destination Ethernet address inside MPLS starts with the number 6. Also see comments in line 641 that talks about a need to improve this heuristic due to potential for problems in how it's currently written.

If you would like to fix it manually, just right-click one of the IPv6-decoded packets and click "Decode as" and under MPLS define "Data label after 1672 as..." and set it to Ethernet PW. It looks like that dissector had a few changes in MPLS next-protocol heuristics between 1.6 and 1.12.

answered 07 Nov '14, 16:08

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

edited 07 Nov '14, 16:22