Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BPF for 'stp' no longer works in tcpdump #678

Open
boisgada opened this issue Mar 7, 2018 · 9 comments

Comments

4 participants
@boisgada
Copy link

commented Mar 7, 2018

I'm not sure when it stopped working, but I have pcap files from Dec 2017 and it was still working then.

tcpdump --version
tcpdump version 4.9.0
libpcap version 1.6.2
OpenSSL 1.0.1t 3 May 2016

tcpdump stp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
13 packets dropped by interface

tcpdump |grep STP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:19:11.123701 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id [intentionally removed], length 42
14:19:12.160293 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id [intentionally removed], length 42
14:19:13.134527 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id [intentionally removed], length 42
14:19:14.173158 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id [intentionally removed], length 42
14:19:15.164322 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id [intentionally removed], length 42
^C283 packets captured
297 packets received by filter
0 packets dropped by kernel
3 packets dropped by interface

uname -a
Linux ntfk0004 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux

@guyharris

This comment has been minimized.

Copy link
Member

commented Mar 7, 2018

So did the kernel version change between then and now?

@boisgada

This comment has been minimized.

Copy link
Author

commented Mar 8, 2018

Perhaps... I have another raspberry pi which has not been updated in over 6 months. I will check the version and verify it still works on that platform.

FYI, the problem is replicated on OSX:
tcpdump --version
tcpdump version tcpdump version 4.9.2 -- Apple version 83.30.1
libpcap version 1.8.1 -- Apple version 79.20.1
LibreSSL 2.2.7

@guyharris

This comment has been minimized.

Copy link
Member

commented Mar 8, 2018

FYI, the problem is replicated on OSX:

If it's happening on macOS, it's not an issue with trying to deal with Linux's handling of VLAN tags (which requires that libpcap do some work to handle, and there are some outstanding bugs about that).

Also, do you have TShark available? If so, could you capture the STP packets with it, running it with `-V', so I can see the full contents of the packet to see whether it's encapsulated with something other than a regular LLC header with the LLC DSAP being 0x42 (which is the only thing the "std" filter has always checked for and currently checks for).

@boisgada

This comment has been minimized.

Copy link
Author

commented Apr 9, 2018

Yes, tshark captures properly:

SHORT Version:

tshark -i eth1 -Y 'stp'
tshark: Lua: Error during loading:
 [string "/usr/share/wireshark/init.lua"]:46: dofile has been disabled due to running Wireshark as superuser. See http://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user.
Running as user "root" and group "root". This could be dangerous.
 Capturing on 'eth1'
 1387   0.775425 Cisco_ad:78:81 -> PVST+        STP 68 Conf. Root = [intentionally deleted]  Cost = 4  Port = 0x8001
 1433   0.780058 Cisco_ad:78:81 -> PVST+        STP 68 Conf. Root = [intentionally deleted] Cost = 4  Port = 0x8001
 1470   0.782703 Cisco_ad:78:81 -> PVST+        STP 68 Conf. Root = [intentionally deleted]  Cost = 4  Port = 0x8001
 1488   0.786389 Cisco_ad:78:81 -> PVST+        STP 68 Conf. Root = [intentionally deleted]  Cost = 4  Port = 0x8001
 1505   0.789554 Cisco_ad:78:81 -> PVST+        STP 68 Conf. Root = [intentionally deleted]  Cost = 4  Port = 0x8001
 1519   0.792927 Cisco_ad:78:81 -> PVST+        STP 68 Conf. Root = [intentionally deleted]  Cost = 4  Port = 0x8001

VERBOSE Version:

 tshark -V -i eth1 -Y 'stp'                                                                                                                                                         
 tshark: Lua: Error during loading:
 [string "/usr/share/wireshark/init.lua"]:46: dofile has been disabled due to running Wireshark as superuser. See http://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user.
 Running as user "root" and group "root". This could be dangerous.
 Capturing on 'eth1'

 Frame 24: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface 0
    Interface id: 0 (eth1)
    Encapsulation type: Ethernet (1)
    Arrival Time: Apr  9, 2018 04:39:08.598294000 CDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1523266748.598294000 seconds
    [Time delta from previous captured frame: 0.003625000 seconds]
    [Time delta from previous displayed frame: 0.003625000 seconds]
    [Time since reference or first frame: 0.069547000 seconds]
    Frame Number: 24
    Frame Length: 68 bytes (544 bits)
    Capture Length: 68 bytes (544 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:vlan:llc:stp]
 Ethernet II, Src: [intentionally deleted], Dst: PVST+ (01:00:0c:cc:cc:cd)
    Destination: PVST+ (01:00:0c:cc:cc:cd)
        Address: PVST+ (01:00:0c:cc:cc:cd)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: [intentionally deleted]
        Address: [intentionally deleted]
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: 802.1Q Virtual LAN (0x8100)
 802.1Q Virtual LAN, PRI: 7, CFI: 0, ID: 10
    111. .... .... .... = Priority: Network Control (7)
    ...0 .... .... .... = CFI: Canonical (0)
    .... 0000 0000 1010 = ID: 10
    Length: 50
 Logical-Link Control
    DSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = IG Bit: Individual
    SSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x03)
    Organization Code: Cisco (0x00000c)
    PID: PVSTP+ (0x010b)
 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: [intentionally deleted]
        Root Bridge Priority: 0
        Root Bridge System ID Extension: 10
        Root Bridge System ID: [intentionally deleted]
    Root Path Cost: 4
    Bridge Identifier: 32768 / 10 / [intentionally deleted]
        Bridge Priority: 32768
        Bridge System ID Extension: 10
        Bridge System ID: [intentionally deleted]
    Port identifier: 0x8001
    Message Age: 1
    Max Age: 20
    Hello Time: 2
    Forward Delay: 15
    Originating VLAN (PVID): 10
        Type: Originating VLAN (0x0000)
        Length: 2
        Originating VLAN: 10
@guyharris

This comment has been minimized.

Copy link
Member

commented Apr 9, 2018

so I can see the full contents of the packet to see whether it's encapsulated with something other than a regular LLC header with the LLC DSAP being 0x42 (which is the only thing the "std" filter has always checked for and currently checks for).

It is encapsulated with something other than a regular LLC header with the LLC DSAP being 0x42 - it's encapsulated with a SNAP header.

So what happens if you run tshark on the captures from December 2007? Does it also show a SNAP header, or does it show an LLC header with a DSAP of 0x42?

@jmayer

This comment has been minimized.

Copy link

commented Apr 9, 2018

The change is, that the "working" capture with tcpdump is a genuine rapid spanning tree capture, while the non-working capture is a cisco per vlan spanning tree capture, so what't probably changed is the switch in the setup. tshark -Y stp specifies a display filter, i.e. we capture everything and only display the packets that match the (decoded) criteria of being "some sort of spanning tree", while tcpdump ... stp specifies a bpf to be executed inside the linux kernel. Without looking at the libpcap source for 'stp' I guess that it will only match on a ieee (and maybe dec) spanning tree BPDU but not on a vendor modified version of that protocol.

@guyharris

This comment has been minimized.

Copy link
Member

commented Apr 9, 2018

Without looking at the libpcap source for 'stp' I guess that it will only match on a ieee (and maybe dec) spanning tree BPDU but not on a vendor modified version of that protocol.

The part of the vendor modification that's relevant here is "Cisco's PVSTP uses SNAP headers and an Ethertype rather than an LLC DSAP of 0x42". As per my earlier comment, libpcap matches STP packets that indicate that it's an STP packet in the DSAP of the 802.2 LLC header, but not STP packets that indicate it's an PVSTP packet in the Ethertype of an 802.2 LLC + SNAP header.

@boisgada

This comment has been minimized.

Copy link
Author

commented Apr 12, 2018

Thank you for the clarification. If I read the updates correctly, libpcap is functioning per the RFC. Would you be able to recommend a BPF syntax which would capture the different STP packets.

If nothing else, I could use tshark to capture the STP packets as the sensors have it installed as well.

@mcr

This comment has been minimized.

Copy link
Member

commented Apr 18, 2019

So it would be nice if we could capture Cisco PVSTP packets as part of "STP"

@mcr mcr added the feature request label Apr 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.