Skip to content

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

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.

Sign up for GitHub

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

Jump to bottom
Closed
max17048 opened this issue Jul 16, 2020 · 8 comments
Closed

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

max17048 opened this issue Jul 16, 2020 · 8 comments

Comments

@max17048
Copy link

max17048 commented Jul 16, 2020 •
edited
Loading

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, type_subtype == 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
Copy link
Contributor

pelwell commented Jul 16, 2020

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

@pelwell
Copy link
Contributor

pelwell commented Jul 20, 2020

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

@max17048
Copy link
Author

More information would be very helpful.

@pelwell
Copy link
Contributor

pelwell commented Jul 21, 2020

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.

@max17048 max17048 mentioned this issue Aug 14, 2020
Closed
@max17048 max17048 mentioned this issue Mar 15, 2021
Open
@max17048 max17048 mentioned this issue Jan 3, 2022
Open
@delaneyb
Copy link

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:

  • Set up an AP with a 20Mhz 802.11n network on channel 6
  • Connect the Pis as well as a laptop to the wireless network
  • On the laptop, start a ping to any other device on the network such that packets must travel over the 2.4GHz frequency in use by the Pi e.g. ping 192.168.0.1 (the AP running the network itself) Note we are not even talking about pinging the Pi itself here, the laptop is pinging the router or any OTHER device on the 2.4GHz network, just to demonstrate this isn’t just a Pi <-> router issue but the 2.4GHz network/channel itself that degrades when we initiate scanning on the Pi.
  • Initiate Bluetooth scanning ON the Raspberry Pi by running the command bluetoothctl scan on

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:

  • 2.4GHz channel selection (1-11)
  • 20MHz or 40MHz
  • Router setting "b/g/n or n only"
  • Router setting "Bluetooth coexistence"
  • Router setting "Airtime Fairness"
  • Placement / signal level
  • Temperature of the Pi
  • Having rebooted the Pi prior to the WiFi network restart
  • Actively running a ping against the Pi
  • Powering off the Pi's BT adapter prior to a restart of the WiFi radio on the router

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
Copy link
Contributor

pelwell commented Mar 29, 2022

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
Copy link
Author

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
Copy link
Contributor

pelwell commented Mar 29, 2022

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.

@pelwell pelwell closed this as completed Mar 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pelwell @delaneyb @max17048