Unable to filter for beacon frames with tcpdump. Bug?

Hello everyone,
I have a weird problem with tcpdump (probably the culprit is libpcap). I am not able to filter for beacon frames only. The right tcpdump filter should be:

type mgt subtype beacon

I compiled an openwrt image from master adding just LUCI and tcpdump few days ago.
I put my wlan cards in monitor mode and then I type:

root@OpenWrt:~# tcpdump -i wlan1 type mgt subtype beacon
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan1, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
^C
0 packets captured
3 packets received by filter
0 packets dropped by kernel

But, as you can see, I am not getting any packet.

If I try to capture without any filter I get a lot of packets, including the beacon frames

root@OpenWrt:~# tcpdump -i wlan1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan1, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
02:52:05.108983 222221699us tsft 1.0 Mb/s 2412 MHz 11b -44dBm signal -46dBm signal antenna 0 -53dBm signal antenna 1 -50dBm signal antenna 2 Beacon (----) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS CH: 1, PRIVACY
02:52:05.135667 222246099us tsft 1.0 Mb/s 2412 MHz 11b -88dBm signal -93dBm signal antenna 0 -93dBm signal antenna 1 -92dBm signal antenna 2 Data IV:480 Pad 20 KeyID 2
02:52:05.191652 222304860us tsft 1.0 Mb/s 2412 MHz 11b -87dBm signal -93dBm signal antenna 0 -89dBm signal antenna 1 -96dBm signal antenna 2 Beacon (----) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 1, PRIVACY
02:52:05.194678 222307784us tsft 1.0 Mb/s 2412 MHz 11b -86dBm signal -89dBm signal antenna 0 -89dBm signal antenna 1 -94dBm signal antenna 2 Beacon (----) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS CH: 1, PRIVACY
02:52:05.211376 222324096us tsft 1.0 Mb/s 2412 MHz 11b -45dBm signal -47dBm signal antenna 0 -57dBm signal antenna 1 -51dBm signal antenna 2 Beacon (----) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS CH: 1, PRIVACY

Moreover if I try to filter for management packets, I get also data packets:

root@OpenWrt:~# tcpdump -i wlan1 type mgt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan1, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
03:01:46.030786 803143162us tsft 1.0 Mb/s 2412 MHz 11b -40dBm signal -44dBm signal antenna 0 -47dBm signal antenna 1 -45dBm signal antenna 2 Data IV:3f2 Pad 20 KeyID 1
03:01:46.031132 803144043us tsft 1.0 Mb/s 2412 MHz 11b -31dBm signal -40dBm signal antenna 0 -31dBm signal antenna 1 -45dBm signal antenna 2 Acknowledgment RA:10:13:31:XX:XX:XX (oui Unknown)
03:01:46.032175 803144486us tsft 1.0 Mb/s 2412 MHz 11b -63dBm signal -69dBm signal antenna 0 -66dBm signal antenna 1 -67dBm signal antenna 2 Data IV:477cfc Pad 20 KeyID 1
03:01:46.141832 803254775us tsft 1.0 Mb/s 2412 MHz 11b -32dBm signal -41dBm signal antenna 0 -33dBm signal antenna 1 -45dBm signal antenna 2 Acknowledgment RA:10:13:31:XX:XX:XX (oui Unknown)

I am using an Archer C7 v2 (QCA9558) and Asus RT-AC51U(MT7620) for testing but I get the same result, so it's not related to the hw.

Am I the only one with this problem? Can someone try the previous commands?

This is the tcpdump and libpcap version:

root@OpenWrt:~# tcpdump -h
tcpdump version 4.9.3
libpcap version 1.9.1 (with TPACKET_V3)

Quick thought, tcpdump-mini or tcpdump package?

Normal "tcpdump"

1 Like

Have you managed to find a fix?
I have a similar issue, running latest snapshot
I actually manage to see beacons frames but cannot filter by mac address

tcpdump -e -ns1500 -i wlan0 type mgt -vv shows this:
12:17:31.017071 864258784us tsft 6.0 Mb/s 5180 MHz 11a -76dBm signal -76dBm signal antenna 0 0us BSSID:AA:BB:CC:DD:EE:FF DA:ff:ff:ff:ff:ff:ff SA:FF:EE:AA:BB:CC:DD Beacon (WiFi-Network) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] ESS CH: 36, PRIVACY
tcpdump -e -ns1500 -i wlan0 ether src AA:BB:CC:DD:EE:FF or:
tcpdump -e -ns1500 -i wlan0 ether src FF:EE:AA:BB:CC:DD or:
tcpdump -e -ns1500 -i wlan0 ether host AA:BB:CC:DD:EE:FF or:
tcpdump -e -ns1500 -i wlan0 ether host FF:EE:AA:BB:CC:DD

Yield nothing.
I used tcpdump-mini but tested with the full version as well.

tcpdump -h gives:

tcpdump version 4.9.3
libpcap version 1.9.1 (with TPACKET_V3)

This is a regression for me, moving from OpenWRT 15.

I didn't find any working solution... I had to filter manually the packet bytes... :frowning:

1 Like

The problem was introduced by https://github.com/openwrt/openwrt/commit/d741b31eb8bbb7a6aa1151c55b3d2506662bf6a8

"echo 0 > /proc/sys/net/core/bpf_jit_enable" (or deleting that line from /etc/sysctl.d/10-default.conf) "solves" the issue.

4 Likes

Same issue here,
DISTRIB_DESCRIPTION='OpenWrt 19.07.2 r10947-65030d81f3'

tcpdump filter shows packets that clearly don't match:

# tcpdump -nlti mon0 'wlan type mgt subtype beacon'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
1477259397871us tsft 24.0 Mb/s 2462 MHz 11g -45dBm signal -52dBm signal antenna 0 -46dBm signal antenna 1 Request-To-Send TA:ac:bc:32:ad:45:7b
1477259399650us tsft 24.0 Mb/s 2462 MHz 11g -45dBm signal -51dBm signal antenna 0 -46dBm signal antenna 1 Request-To-Send TA:ac:bc:32:ad:45:7b
1477259720954us tsft 24.0 Mb/s 2462 MHz 11g -46dBm signal -53dBm signal antenna 0 -47dBm signal antenna 1 Request-To-Send TA:ac:bc:32:ad:45:7b
1477259744055us tsft 24.0 Mb/s 2462 MHz 11g -45dBm signal -52dBm signal antenna 0 -46dBm signal antenna 1 Request-To-Send TA:ac:bc:32:ad:45:7b
1477259919883us tsft 24.0 Mb/s 2462 MHz 11g -45dBm signal -52dBm signal antenna 0 -46dBm signal antenna 1 Request-To-Send TA:ac:bc:32:ad:45:7b

confirmed bpf_jit_enable=0 fixes the problem.

In my case (~600 pps), the CPU usage seems still very low.

Hello, I had the same issue, I tried the following filter:
tcpdump -l -i wlan0 -tttt -e -s 256 type mgt subtype probe-req

I tried both in 2.4GHz and 5GHz and somehow tcpdump managed to collect very few probe requests, but there were mostly probe responses. However the same filter seems to work fine for probe-resp subtype.

I confirmed that bpf_jit_enable=0 fixes the problem.