mt76x2u: multicast stops working in IBSS
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 888
- Forks
- 436
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I'm putting "mt76x2u" in the title because this was where I saw the behaviour, not sure if happens in more places.
I'm using an Netgear A6210 (0846:9053) and setting it in IBSS mode and adding a default route for multicast traffic to the device.
Then I start sending multicast traffic with iperf (v2):
iperf -u -c 224.224.2.5 -b 37M -t 3500 -i 1
Confirm it is working by running monitor mode in another interface and checking the packets getting received.
After a few minutes later (sometimes in the first 20 seconds, sometimes almost a minute later) of continues multicast traffic the transmission stops on the iperf, only resuming if I send a ping to the same multicast address.
Other wireless interfaces don't have the issue (tested with an ath9k).
This was tested with kernel 5.4.0-52-generic, but also in an raspberry pi with kernel 5.9.1-v7+ the same test causes a crash in mt76x02_mac_work (dmesg attached).
dmesg_crash.log
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the IBSS multicast test with iperf and the mt76x2u device, then review the attached dmesg_crash.log and the mt76x02_mac_work path mentioned in the report. Done means multicast transmission continues without requiring a ping and the Raspberry Pi scenario no longer crashes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- networking, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100