Wireshark-bugs: [Wireshark-bugs] [Bug 2254] Incorrect allocation/classification of "Type" fileld
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2254
Jewgenij.Bytschkow@xxxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Jewgenij.Bytschkow@t-
| |systems.com
--- Comment #2 from Jewgenij.Bytschkow@xxxxxxxxxxxxx 2008-02-11 15:18:28 GMT ---
(In reply to comment #1)
> with all the 802.1Q information under the "Ethernet II" top-level item, rather
> than under a separate "802.1Q" protocol, would be a correct way of showing
> that.
Yes. But each VLAN TAG (there could be several VLAN TAGs in a frame!) should be
clearly structured under the "Ethernet II" top-level node - such a way as it is
currently implemented in Wireshark: a sub-node "802.1Q Virtua LAN", with the
TPID (2 byte) and TCI (2 byte) fields underlaid. The EtherType field should
stand in frame after(!) all VLAN TAGs - on the same level like "802.1Q Virtua
LAN" under "Ethernet II" top-level.
Of course, a VLAN TAG in a frame representation should not be treated as an
"encapsulated protocol". A VLAN TAG does belong to the Ethernet II level, but
its structured presence (like now) helps to promptly identify whether the
captured frame contains VLAN TAG(s) or not.
It is also essential to notify, that:
a) the EtherType field MUST be uncoupled from "802.1Q Virtua LAN", i.e. not be
classified as a "VLAN TAG field",
b) each VLAN TAG must correctly consist of its TPID (2 byte) and TCI (2 byte)
fields (in this order!),
c) the VLAN TPID of the 1-st VLAN TAG should NOT be falsely
interpreted/classified as the "EthernetType" field.
Wireshark (and Ethereal earlier) make all these classification mistakes
(a-b)for frames containing VLAN TAGs.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
