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

FS#2197 - default kernel option CONFIG_BPF_JIT=y breaking bpf filtering on 802.11 monitor mode traffic #7044

Open
openwrt-bot opened this issue Mar 21, 2019 · 5 comments
Labels
flyspray kernel pull request/issue with Linux kernel related changes

Comments

@openwrt-bot
Copy link

Tyler:

Between 18.06.2 and the Trunk the kernel option CONFIG_BPF_JIT=y was added.

With JIT enabled, a simple beacon filter shows no traffic.
With JIT disabled, the filter works normally.

Device: ar71xx generic device (gl-mifi):

Test:
put the radio card in monitor mode:
iw wlan0 set type monitor
ifconfig wlan0 up
iw wlan0 set channel 1 # some channel with an AP

tcpdump -i wlan0
see lots of traffic and beacons

tcpdump -i wlan0 wlan type mgt subtype beacon
no traffic

Fix:
echo 0 > /proc/sys/net/core/bpf_jit_enable

tcpdump -i wlan0 wlan type mgt subtype beacon
see lots of beacons

More detail:
Testing on my side, with JIT enabled, it seems to be computing the offset to the start of the wlan packet incorrectly. In my case, the offset was off by +16 bytes. A filter of "wlan[0] == 0x80" should show beacons, because the type/subtype field is the first byte of the wlan packet. With JIT enabled, wlan[0] was equal to the first byte of the addr3/bssid field (the first byte of my AP's MAC address), which is 16 bytes later in the packet.

@openwrt-bot
Copy link
Author

adde88:

I can confirm this issue.

I stumbled over this while debugging reaver for the latest openwrt-19.07 on my wifi-pineapple (ar71xx)

Wash/reaver would not find beacon frames like it usually does.
Disabling **bpf_jit_enable **made wash work like normal.

We're a bit scared that this is a bug that can be leveraged remotely to gain root access (RCE) to the device by simply sending malformed packets to it.

Here's a link to the issue on reaver.
t6x/reaver-wps-fork-t6x#288

@openwrt-bot
Copy link
Author

foxtrot:

Hello,

I can also confirm this issue is present on ath79 and ar71xx targets. Compiling a new firmware with kernel option CONFIG_BPF_JIT disabled will result in a working image out of the box.

@openwrt-bot
Copy link
Author

cancian:

I found this issue while trying to monitor my wan interface using iftop, and it would not show any ipv6 addresses.

I downgraded to version 18, and there this issue doesn't exist, so I tracked the differences on the /etc folder of both 19.x and 18.x versions, and found the culprit to be this line:

net.core.bpf_jit_enable=1

In the file:
/etc/sysctl.d/10-default.conf

@openwrt-bot
Copy link
Author

guidosarducci:

I routinely monitor IPv6 traffic with iftop (e.g. on lan) and don't see the issue on a ar71xx/generic arch running 19.07.6. Perhaps your iftop problem is not related to the OP?

Also, on these MIPS32 platforms there's still no eBPF JIT, just the same cBPF JIT that's been around for years and widely used for accelerating libpcap. But I can't speak to the internals of wireless monitor mode and how it interacts with BPF.

Do the wireless problems still happen on the latest master or 21.02 snapshot?

@aparcar aparcar added the kernel pull request/issue with Linux kernel related changes label Feb 22, 2022
@biemster
Copy link

I still see this on 21.02 snapshot, on a QCA9533. I'll ping back when I try the latest main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray kernel pull request/issue with Linux kernel related changes
Projects
None yet
Development

No branches or pull requests

3 participants