[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2254

           Summary: Incorrect allocation/classification of "Type" filelds
                    and incorrect representation of 802.1Q VLAN TAGs in
                    VLAN-tagged frames
           Product: Wireshark
           Version: 0.99.7
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: Jewgenij.Bytschkow@xxxxxxxxxxxxx


Created an attachment (id=1454)
 --> (http://bugs.wireshark.org/bugzilla/attachment.cgi?id=1454)
two traces with VLAN-tagged frames (single-tagged, double-tagged)

Build Information:
Version 0.99.7 (SVN Rev 23910)

Copyright 1998-2007 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 with GTK+ 2.12.1, with GLib 2.14.3, with WinPcap (version unknown),
with libz 1.2.3, with libpcre 6.4, with SMI 0.4.5, with ADNS, with Lua 5.1,
with
GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio PortAudio
V19-devel, with AirPcap.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.

Built using Microsoft Visual C++ 6.0 build 8804

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.

--
Wireshark makes several representation errors, when it allocates and
classificates the "EtherType" and "802.1QTagType" fields. For example, 
Wireshark classifies the field 802.1QTagType (VLAN Tag Protocol Identifier, 2
Bytes) as an EthernetType (2 Bytes) and falsely places it prior the 1-st
"802.1Q VLAN" section.

The Wireshark representation of 802.1Q VLAN TAGs in VLAN-tagged frames is also
incorrect because all "Type" fields (Ethernet-Type and VLAN-TPID) are shifted
in the shown frame structure. So, the Wireshark faultily represents the VLAN
TAGs in a frame as starting with TCI (VLAN Tag Control Information field, 2
Bytes) followed by TPID (VLAN Protocol Type field). That is wrong! The correct
fields sequence in a VLAN TAG should be: TPID (VLAN Protocol Type) followed by
TCI (VLAN Tag Control Information), i.e. contrariwise to the currently shown by
Wireshark.

The error concerns both graphical (window) and exported (textual)
representations, both frames with a single VLAN TAG and with several (Q-in-Q)
VLAN TAGs.

IEEE 802.3 Ethernet frames without VLAN TAGs have following format:

<Dst_MAC> + <Src_MAC> + <EtherType/Length> + <Ethernet_Payload>
(6 Byte)    (6 Byte)         (2 Byte)

In case of VLAN-Tagged Ethernet frames, one or more VLAN TAG(s) are placed in
the frame between(!) the fields <Src_MAC_Address> and <EtherType>:

<Dst_MAC> + <Src_MAC> + <VLAN_TAG>[<VLAN_TAG>...] + <EtherType> + 
(6 Byte)    (6 Byte)     (4 Byte)  ...                (2 Byte)

+ <Ethernet_Payload>

Incorrect allocation/classification of "Type" filelds in the Wireshark
representation of VLAN-tagged frames can be illustrated e.g. with the following
textual layout of the Frame #7 in the submitted capture file vlan.pcap (please
see the comments below, at right hand of the arrows):

Frame 7 (1518 bytes on wire, 1518 bytes captured)
    Arrival Time: Nov  5, 1999 19:20:40.065843000
    ...
    [Protocols in frame: eth:vlan:ip:tcp:x11]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: 3com_9f:b1:f3 (00:60:08:9f:b1:f3), Dst: AniCommu_40:ef:24
(00:40:05:40:ef:24)
    Destination: AniCommu_40:ef:24 (00:40:05:40:ef:24)
        Address: AniCommu_40:ef:24 (00:40:05:40:ef:24)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: 3com_9f:b1:f3 (00:60:08:9f:b1:f3)
        Address: 3com_9f:b1:f3 (00:60:08:9f:b1:f3)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: 802.1Q Virtual LAN (0x8100)   <-------  /* These two bytes are
802.1QTagType (NOT an Ethernet Type field) and should belong to the following
802.1Q VLAN TAG. */
802.1Q Virtual LAN
    000. .... .... .... = Priority: 0
    ...0 .... .... .... = CFI: 0
    .... 0000 0010 0000 = ID: 32
    Type: IP (0x0800)                   <-------  /* This is the Ethernet Type
field, which follows directly after the VLAN TAG(s). It does NOT belong to the
VLAN TAG. */
Internet Protocol, Src: 131.151.32.21 (131.151.32.21), Dst: 131.151.32.129
(131.151.32.129)
    Version: 4
    Header length: 20 bytes
    ...
    ...


===A correct representation of such a frame with a single VLAN TAG should look
like that:

Frame 7 (1518 bytes on wire, 1518 bytes captured)
    ...
    ...
Ethernet II, Src: 3com_9f:b1:f3 (00:60:08:9f:b1:f3), Dst: AniCommu_40:ef:24
(00:40:05:40:ef:24)
    Destination: AniCommu_40:ef:24 (00:40:05:40:ef:24)
        Address: AniCommu_40:ef:24 (00:40:05:40:ef:24)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: 3com_9f:b1:f3 (00:60:08:9f:b1:f3)
        Address: 3com_9f:b1:f3 (00:60:08:9f:b1:f3)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)

802.1Q Virtual LAN
    Type: 802.1Q Virtual LAN (0x8100)   <------- /* VLAN TAG Protocol
Identifier, 2 Bytes. */
    000. .... .... .... = Priority: 0
    ...0 .... .... .... = CFI: 0
    .... 0000 0010 0000 = ID: 32

Type: IP (0x0800)       <-------  /* The Ethernet Type field follows directly
after the VLAN TAG(s). */

Internet Protocol, Src: 131.151.32.21 (131.151.32.21), Dst: 131.151.32.129
(131.151.32.129)
    Version: 4
    Header length: 20 bytes
    ...
    ...


===In case of two VLAN TAGs in a frame for stacked VLAN (capture file
stacked_vlan.pcap):

Frame 1 (44 bytes on wire, 44 bytes captured)
    Arrival Time: Oct  5, 2007 12:49:06.251902000
    ...
    ...
    [Protocols in frame: eth:vlan:vlan:pppoes:ppp:lcp]
Ethernet II, Src: Wistron_13:31:a3 (00:0a:e4:13:31:a3), Dst: Siara_02:17:35
(00:30:88:02:17:35)
    Destination: Siara_02:17:35 (00:30:88:02:17:35)
        Address: Siara_02:17:35 (00:30:88:02:17:35)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: Wistron_13:31:a3 (00:0a:e4:13:31:a3)
        Address: Wistron_13:31:a3 (00:0a:e4:13:31:a3)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: 802.1Q Virtual LAN (0x8100)   <-------  /* These two bytes are
802.1QTagType (NOT an Ethernet Type field) and should belong to the following
1-st 802.1Q VLAN TAG. */

802.1Q Virtual LAN
    000. .... .... .... = Priority: 0
    ...0 .... .... .... = CFI: 0
    .... 0011 1001 1100 = ID: 924
    Type: 802.1Q Virtual LAN (0x8100)   <-------  /* This is the Ethernet Type
field, which belong to the following 2-nd 802.1Q VLAN TAG. */
802.1Q Virtual LAN
    000. .... .... .... = Priority: 0
    ...0 .... .... .... = CFI: 0
    .... 0000 1000 0000 = ID: 128
    Type: PPPoE Session (0x8864)        <-------  /* This is the Ethernet Type
field, which follows directly after the VLAN TAGs. It does NOT belong to the
VLAN TAG! */
PPP-over-Ethernet Session
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Session Data (0x00)
    Session ID: 0x0102
    Payload Length: 16
...
...


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.