https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6455
Summary: MPLS Packets Containing Ethernet Broadcast Decoded
Incorrectly
Product: Wireshark
Version: 1.6.2
Platform: x86-64
OS/Version: Windows 7
Status: NEW
Severity: Major
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: wireshark@xxxxxxxxxxx
Created an attachment (id=7222)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7222)
As per description.
Build Information:
Version 1.6.2 (SVN Rev 38931 from /trunk-1.6)
Copyright 1998-2011 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, without libpcre, without
SMI, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3, with
Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio V19-devel (built Sep
7 2011), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.10.3, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 21022
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Please refer to attached packet capture. The packets are fairly complex and
have quite a few layers. For the majority of packets Wireshark interprets
everything correctly. For packets where the inner Ethernet packet (EoMPLS) has
a destination MAC address of ff:ff:ff:ff:ff:ff the interpretation ends up with
and extra "PW Ethernet Control Word" and misses the 802.1q vlan tag (both 4
bytes).
Packet 1 in the capture shows an ARP request with the issue.
Packet 2 in the capture shows an ICMP request interpreted correctly.
Packet 3 in the capture shows an ICMP request to L3/L2 broadcast with the issue
Packet 4 in the capture shows an ICMP request to a multicast address
interpreted correctly.
Looking at packet 1 Wireshark interprets as follows
00 1d 71 73 63 c0 -> dst mac
40 55 39 53 8f a8 -> src mac
81 00 00 02 -> dot1q vlan 2
81 00 02 bc -> dot1q vlan 700
88 47 00 01 71 fe -> MPLS header
ff ff ff ff -> ############ PW Ethernet Control Word #############
ff ff 00 23 8b 57 -> dst mac
dc f8 81 00 00 de -> src mac
08 06 -> ARP
00 0108 00 06 04 00 01-> ARPy stuff (hardware type, protocol type, hardware
size, protocol size, op code)
00 23 8b 57 dc f8 -> sender mac
0a 0a 0a 01 -> sender IP
00 00 00 00 00 00 -> target mac
0a 0a 0a 02 -> target IP
00 00 00 00 00 00 00 00 00 00 00 00 00 00 -> trailer
It should be interpreted like this
00 1d 71 73 63 c0 -> dst mac
40 55 39 53 8f a8 -> src mac
81 00 00 02 -> dot1q vlan 2
81 00 02 bc -> dot1q vlan 700
88 47 00 01 71 fe -> MPLS header
ff ff ff ff ff ff -> dst mac
00 23 8b 57 dc f8 -> src mac
81 00 00 de -> ##### dot1q vlan 222 #########
08 06 -> ARP
00 0108 00 06 04 00 01-> ARPy stuff (hardware type, protocol type, hardware
size, protocol size, op code)
00 23 8b 57 dc f8 -> sender mac
0a 0a 0a 01 -> sender IP
00 00 00 00 00 00 -> target mac
0a 0a 0a 02 -> target IP
00 00 00 00 00 00 00 00 00 00 00 00 00 00 -> trailer
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.