search

the-tcpdump-group / libpcap

the LIBpcap interface to various kernel packet capture mechanism
https://www.tcpdump.org/
Other
2.7k stars 851 forks source link

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

Open boisgada opened 6 years ago

boisgada commented 6 years ago

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 commented 6 years ago

So did the kernel version change between then and now?

boisgada commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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

alarig commented 3 years ago

As the packet has a LLC EtherType, you can use those filters:

       llc    True if the packet has an 802.2 LLC header.  This includes:

              Ethernet  packets  with  a length field rather than a type field
              that aren't raw NetWare-over-802.3 packets;

              IEEE 802.11 data packets;

              Token Ring packets (no check is done for LLC frames);

              FDDI packets (no check is done for LLC frames);

              LLC-encapsulated ATM packets, for SunATM on Solaris.

       llc type
              True if the packet has an 802.2 LLC header and has the specified
              type.  type can be one of:

              i      Information (I) PDUs

              s      Supervisory (S) PDUs

              u      Unnumbered (U) PDUs

              rr     Receiver Ready (RR) S PDUs

              rnr    Receiver Not Ready (RNR) S PDUs

              rej    Reject (REJ) S PDUs

              ui     Unnumbered Information (UI) U PDUs

              ua     Unnumbered Acknowledgment (UA) U PDUs

              disc   Disconnect (DISC) U PDUs

              sabme  Set Asynchronous Balanced Mode Extended (SABME) U PDUs

              test   Test (TEST) U PDUs

              xid    Exchange Identification (XID) U PDUs

              frmr   Frame Reject (FRMR) U PDUs
infrastation commented 3 years ago

To avoid unnecessary surprises, would it make sense to keep the existing "stp" matcher as it is now, and to try adding a separate "pvst" matcher?

Keulk commented 3 years ago

As the packet has a LLC EtherType, you can use those filters:

       llc    True if the packet has an 802.2 LLC header.  This includes:

              Ethernet  packets  with  a length field rather than a type field
              that aren't raw NetWare-over-802.3 packets;

              IEEE 802.11 data packets;

              Token Ring packets (no check is done for LLC frames);

              FDDI packets (no check is done for LLC frames);

              LLC-encapsulated ATM packets, for SunATM on Solaris.

       llc type
              True if the packet has an 802.2 LLC header and has the specified
              type.  type can be one of:

              i      Information (I) PDUs

              s      Supervisory (S) PDUs

              u      Unnumbered (U) PDUs

              rr     Receiver Ready (RR) S PDUs

              rnr    Receiver Not Ready (RNR) S PDUs

              rej    Reject (REJ) S PDUs

              ui     Unnumbered Information (UI) U PDUs

              ua     Unnumbered Acknowledgment (UA) U PDUs

              disc   Disconnect (DISC) U PDUs

              sabme  Set Asynchronous Balanced Mode Extended (SABME) U PDUs

              test   Test (TEST) U PDUs

              xid    Exchange Identification (XID) U PDUs

              frmr   Frame Reject (FRMR) U PDUs

I wish I could simply use the 'llc' filter, but it gets rejected with this message : 'llc' supported only on raw ATM

tcpdump version 4.9.0 libpcap version 1.5.3

guyharris commented 3 years ago

I wish I could simply use the 'llc' filter, but it gets rejected with this message : 'llc' supported only on raw ATM

tcpdump version 4.9.0 libpcap version 1.5.3

You can use it, but you'll need a newer version of libpcap; that issue was fixed in May 2014, so you'd need 1.6.1 or later.

guyharris commented 3 years ago

As the packet has a LLC EtherType, you can use those filters:

You can, with libpcap 1.6.1 or later (unless you're capturing on raw ATM, which you almost certainly aren't), but all that will let you do is capture all packets with an LLC header and filter out all packets without an LLC header. That may be sufficient, but you'll still see non-STP/PVSTP LLC-header packets if there are any.