search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.15k stars 4.99k forks source link

Raspberry as CTS-Flooder (internal WLAN & BT) #3727

Closed max17048 closed 2 years ago

max17048 commented 4 years ago

Describe the bug If you use the internal WLAN(2.4GHz) and Bluetooth, the 2.4GHZ-band usually messed up. Often, users use a external WIFI- or Bluetooth-Dongle to fix the problem. This here may point to the reason of the problem:

To reproduce I used tshark to capture this data.

For example, you use a Pi with the Raspberry-WLAN-MAC B8:27:EB:xx:yy:zz with internal WLAN(2.4GHz) & BT switched on. There appear a additional Broadcom-MAC E0:3E:44:08:yy:zz in the air. This address starts CTS-Flooding with an interval of appr. 3.75ms and mess up the 2.4GHz-Band. The MAC is never connectet to any other, only flooding CTS. If you disable BT by dtoverlay=disable-bt in /boot/config.txt or stop bluetoothctl scan on, the Broadcom-MAC and the CTS-Flooding disappears.

Testsetup used:

Rpi Zero W, 3B, 4B - all on actual Buster-Lite - connected zu a 2.4GHz accesspoint (Atheros-Chips). tshark to scan the network. TL-WND722N (Atheros) for scanning the network in promiscuous mode on the Pi.

Edit: Found the reason of missed Control-Frames. See 2nd edit below. I don't know why the TL-WND722N provide the CF by default. Be aware: If you use a Pi to scan the network, you should use a TL-WND722N because all other adapter I testet dosn't show the Control-Frames (wlan.fc.type_subtype 24-31); don't know why. But this may something completely different. Better use tshark or wireshark on a Linux-PC, afterwards I used Ubuntu 18.04, there are no missing Control-Frames on different adapter.

Start the test. Run the Pi with internal WLAN(2.4GHz) and BT switched on, start bluetoothctl:

sudo bluetoothctl power on
sudo bluetoothctl scan on  # After that point, the CTS-Flooding starts with the mysterious Broadcom-MAC, ~12.000 per hour

At this point I start reading Bluetooth with tshark continuously. So there are a lot additional useless CTS, ~260.000 per hour.

On the wire-/tshark-machine, set the adapter to the AP-channel your Pi is connected to, also set it to promiscuous mode: Edit: changed none to control

sudo iw dev <WLAN-Adapter> set channel <your AP-channel>
sudo ip link set <WLAN-Adapter> down && iw <WLAN-Adapter> set monitor control && link set <WLAN-Adapter> up

Start Wireshark or tshark:

[sudo] tshark -I -i <WLAN-Adapter> -a duration:120 -w /tmp/tshark.bin   # Only tshark; write 120 seconds

To read the interesting fields in the 120-seconds tshark-file. Check the wireshark filters described here: 

[sudo] tshark -r /tmp/tshark.bin -T fields -e wlan.fc.type_subtype -e wlan.sa -e wlan.bssid -e wlan.ra -e wlan.ta -e wlan.da -e wlan_radio.channel > junk

grep -i E0:3E:44:08:yy:zz junk  # look 4 the wlan.ra

There, in my testsetup, I find the Broadcom-MAC E0:3E:44:08:yy:zz, typesubtype == 28. Testing on Zero W and 3B, there is also a 2nd Broadcom-MAC E0:3E:44:04:yy:zz on the same Pi, also sending unmotivated CTS-Frames to nowhere. But between 20 an 200 per hour, so no big deal. On 4B this 04_-MAC dosn't appear. Maybe this points to the different Broadcom-chip.

Actual behaviour Seems there is an accidentally redirection from the Raspberry-MAC to the original Broadcom-MAC.

System

Additional context As this happens to the tshark-receiver address (wlan.ra), I also spoofed the Raspberry-MAC (LAN, WLAN) for test to exclude the CTS-Flooding is initiated by the AP. So the AP (Atheros) dosn't know that there are Broadcom-chips around.

pelwell commented 4 years ago

Weird - I've volleyed this one straight to Cypress.

pelwell commented 4 years ago

Cypress's response suggested this is expected, but the message was so brief that I've requested more information.

max17048 commented 4 years ago

More information would be very helpful.

pelwell commented 4 years ago

Indeed. The impression I got is that it is part of the coexistence mechanism between the WiFi and BT halves of the combo chip, but saying more would be speculation at this point.

delaneyb commented 2 years ago

I think this might be the explanation of what is probably the most frustrating issue I have ever dealt with. I won't go into detail of what I went through to conclude that the solution for us was to simply use a 5GHz ac router or to buy 2.4GHz wifi dongles for all our Pis, but here are some notes I took while trying to get to the bottom of this issue:

While performing Bluetooth scanning, the Raspberry Pi 4 Model B will produce interference on the channel used by the 2.4GHz WiFi network it is currently connected to. Interference does not seem to be created on any other 2.4GHz channels, and no interference seems to be created in either 5 or 2.4GHz channels if the Pi is connected to a 5GHz WiFi network.

For example:

We observe the following:

image

It seems that to perfom Bluetooth scanning, the adapter on the Pi sweeps through frequencies in the 2.4GHz spectrum. When it crosses certain frequencies, interference on the 2.4GHz network is produced somehow. Note that the ping shows the time for the router to respond to a message from the laptop - the Pi itself is not involved in this communication anywhwere. This would mean either the router is very preoccupied with some other work for those periods where the ping is spiking, OR there is RF interference being produced by the Pi’s Bluetooth scanning.

This is the effect that a single Pi has on the 2.4GHz network while Bluetooth scanning.

Now we simultaneously enable Bluetooth scanning on 10 Raspberry Pis connected to the same 2.4GHz network

This is the result (bt scanning was run for a 35s period and then stopped on all pis at once):

image

The entire network essentially becomes unusable while the simultaneous Bluetooth scans of multiple Pis connected to it are underway (red indicates ping packets that are dropped/completely lost).

When a completely separate AP is configured to use the same 2.4GHz channel as the AP the raspberry Pis are connected to, and we connect the laptop to that network instead and issue the same sleep + bluetoothctl scan on command, the laptop’s ping times to that separate AP experience identical interference and dropouts as when connected to the same AP as the Raspberry Pis. Effectively, the raspberry Pis jam all communications on the 2.4GHz channel of the network they are connected to - it is not something just related to a single 2.4GHz network or AP. Therefore this issue seems to stem from some interaction between the WiFi and Bluetooth radios of the Raspberry Pi 4B. It seems that enabling Bluetooth scanning causes interference to be spewed into the 2.4GHz channel of the network the Pi’s WiFi adapter is connected to.

Very oddly, occasionally - maybe 20-50% of the time I can't say for sure I feel like there was some factor affecting this that I couldn't find - I could run the Bluetooth scanning with NO interference produced on the 2.4GHz network. sudo ifconfig wlan0 down; sleep 1; sudo ifconfig wlan0 up would almost always cause the interference issue to reappear upon a subsequent scan on. No consistent relation was observed between running Bluetooth scanning and NOT getting any interference on the 2.4 network and:

The Pi's themselves:

> cat /etc/rpi-issue
Raspberry Pi reference 2021-05-07
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, dcfd74d7d1fa293065ac6d565711e9ff891fe2b8, stage2
> cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
> uname -a
Linux yb-2 5.10.63-v7l+ #1488 SMP Thu Nov 18 16:15:28 GMT 2021 armv7l GNU/Linux
pelwell commented 2 years ago

There has been an issue open with Cypress/Infineon since June 17 2020. In the most recent response they (re)state that this behaviour is expected, and that it cannot be modified or disabled.

max17048 commented 2 years ago

There has been an issue open with Cypress/Infineon since June 17 2020. In the most recent response they (re)state that this behaviour is expected, and that it cannot be modified or disabled.

Heavy stuff.

I see this behavior a lot of times outside my AP-environment. Mostly by newer Apple iPhones w/ Cypress-Chip.

What are this both MACs are for? Looks like backdoors.

Can you ask for documentation? I doesn't found any datasheets.

pelwell commented 2 years ago

I don't know why it uses dedicated MAC addresses rather than using the devices real WLAN MAC, but the WLAN half of the device is claiming that it needs some air time in order that the Bluetooth half has a quiet window to use.

There won't be any documentation - this isn't a configurable parameter, it's just how they choose to do things.