| Bug ID |
9236
|
| Summary |
Cannot dissect "nested" LLC/STP payload from an 802.11 bridge device
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
SVN
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Trivial
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 11715 [details]
A trace file containing examples of these packets
Build Information:
Version 1.11.0-SVN-51333 (SVN Rev Unknown from unknown)
Copyright 1998-2013 Gerald Combs <[email protected]> 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 (32-bit) with GTK+ 3.6.0, with Cairo 1.12.2, with Pango 1.30.1, with
GLib 2.34.1, with libpcap, with libz 1.2.7, without POSIX capabilities, with
libnl 1, without SMI, without c-ares, without ADNS, with Lua 5.1, without
Python, with GnuTLS 2.12.14, with Gcrypt 1.5.0, with MIT Kerberos, without
GeoIP, without PortAudio, without AirPcap.
Running on Linux 3.5.0-28-generic, with locale ja_JP.UTF-8, with libpcap
version
1.5.0-PRE-GIT_2013_04_17, with libz 1.2.7, GnuTLS 2.12.14, Gcrypt 1.5.0.
Built using gcc 4.7.2.
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
It appears that Wireshark is unable to further decapsulate the "nested" LLC
payload from some packets (e.g. 19) within the attached trace file (generated
by a generic 802.11 WDS bridging device on my home WLAN), in order to dissect
the Spanning Tree Protocol data contained within.
For an unencapsulated STP packet, things seem fine:
IEEE 802.11 QoS Data, Flags: .......T
Type/Subtype: QoS Data (0x28)
Frame Control Field: 0x8801
.... ..00 = Version: 0
.... 10.. = Type: Data frame (2)
1000 .... = Subtype: 8
Flags: 0x01
.... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1
>From DS: 0) (0x01)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
.000 0000 0000 0000 = Duration: 0 microseconds
Receiver address: Netgear_bf:6f:8e (c4:3d:c7:bf:6f:8e)
BSS Id: Netgear_bf:6f:8e (c4:3d:c7:bf:6f:8e)
Transmitter address: Winstars_97:02:08 (80:3f:5d:97:02:08)
Source address: Winstars_97:02:08 (80:3f:5d:97:02:08)
Destination address: Spanning-tree-(for-bridges)_00 (01:80:c2:00:00:00)
Fragment number: 0
Sequence number: 947
Qos Control: 0x0000
.... .... .... 0000 = TID: 0
[.... .... .... .000 = Priority: Best Effort (Best Effort) (0)]
.... .... ...0 .... = QoS bit 4: Bits 8-15 of QoS Control field are
TXOP Duration Requested
.... .... .00. .... = Ack Policy: Normal Ack (0x0000)
.... .... 0... .... = Payload Type: MSDU
0000 0000 .... .... = TXOP Duration Requested: 0 (no TXOP requested)
Logical-Link Control
DSAP: Spanning Tree BPDU (0x42)
IG Bit: Individual
SSAP: Spanning Tree BPDU (0x42)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
Spanning Tree Protocol
Protocol Identifier: Spanning Tree Protocol (0x0000)
Protocol Version Identifier: Spanning Tree (0)
BPDU Type: Configuration (0x00)
BPDU flags: 0x00
0... .... = Topology Change Acknowledgment: No
.... ...0 = Topology Change: No
Root Identifier: 32768 / 0 / 80:3f:5d:97:02:08
Root Bridge Priority: 32768
Root Bridge System ID Extension: 0
Root Bridge System ID: Winstars_97:02:08 (80:3f:5d:97:02:08)
Root Path Cost: 0
Bridge Identifier: 32768 / 0 / 80:3f:5d:97:02:08
Bridge Priority: 32768
Bridge System ID Extension: 0
Bridge System ID: Winstars_97:02:08 (80:3f:5d:97:02:08)
Port identifier: 0x8002
Message Age: 0
Max Age: 20
Hello Time: 2
Forward Delay: 4
0000 00 00 12 00 2e 48 00 00 00 6c 9e 09 c0 00 bb 03 .....H...l......
0010 00 00 88 01 00 00 c4 3d c7 bf 6f 8e 80 3f 5d 97 .......=..o..?].
0020 02 08 01 80 c2 00 00 00 30 3b 00 00 42 42 03 00 ........0;..BB..
0030 00 00 00 00 80 00 80 3f 5d 97 02 08 00 00 00 00 .......?].......
0040 80 00 80 3f 5d 97 02 08 80 02 00 00 14 00 02 00 ...?]...........
0050 04 00 ..
However, the packets with encapsulated/"dual-layer" LLC + STP payloads look
like:
IEEE 802.11 Data, Flags: ......F.
Type/Subtype: Data (0x20)
Frame Control Field: 0x0802
.... ..00 = Version: 0
.... 10.. = Type: Data frame (2)
0000 .... = Subtype: 0
Flags: 0x02
.... ..10 = DS status: Frame from DS to a STA via AP(To DS: 0 From
DS: 1) (0x02)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
.000 0000 0000 0000 = Duration: 0 microseconds
Receiver address: Spanning-tree-(for-bridges)_00 (01:80:c2:00:00:00)
Destination address: Spanning-tree-(for-bridges)_00 (01:80:c2:00:00:00)
Transmitter address: Netgear_bf:6f:8e (c4:3d:c7:bf:6f:8e)
BSS Id: Netgear_bf:6f:8e (c4:3d:c7:bf:6f:8e)
Source address: Winstars_97:02:08 (80:3f:5d:97:02:08)
Fragment number: 0
Sequence number: 2043
Logical-Link Control
DSAP: SNAP (0xaa)
IG Bit: Individual
SSAP: SNAP (0xaa)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
Organization Code: Encapsulated Ethernet (0x000000)
Type: Unknown (0x0034)
Data (38 bytes)
Data: 42420300000000008000803f5d970208000000008000803f...
[Length: 38]
0000 00 00 12 00 2e 48 00 00 00 02 9e 09 a0 00 ad 03 .....H..........
0010 00 00 08 02 00 00 01 80 c2 00 00 00 c4 3d c7 bf .............=..
0020 6f 8e 80 3f 5d 97 02 08 b0 7f aa aa 03 00 00 00 o..?]...........
0030 00 34 42 42 03 00 00 00 00 00 80 00 80 3f 5d 97 .4BB.........?].
0040 02 08 00 00 00 00 80 00 80 3f 5d 97 02 08 80 02 .........?].....
0050 00 00 14 00 02 00 04 00 ........
Judging from the generic "data" payload, it would be necessary to invoke the
LLC dissector on those 38 undissected bytes - although I don't know if the
"type" value of 0x0034 is defined in any specific standard, or if attempting to
fix this would break dissection for others...
You are receiving this mail because:
- You are watching all bug changes.
