Radiotap Frame Capture Issue with Qualcomm IPQ6018 (Yuncore FAP650, ath11k driver)
Issue Description
When capturing raw frames in monitor mode on a Qualcomm IPQ6018-based device (Yuncore FAP650 https://github.com/openwrt/openwrt/pull/14745) or another ipq6018, ipq8072 device using the ath11k driver, the captured radiotap frames contain an extra 8 bytes of junk data.
I have tried the same on another qualcommax device (yuncore ax880 https://github.com/openwrt/openwrt/pull/13853). The same problem.
Steps to Reproduce
- Set up the wireless interface in monitor mode and capture interface data.
iw phy0 interface add wlan0 type monitor
ip link set wlan0 up
iw wlan0 set channel 36
tcpdump -i wlan0 -w /tmp/radio.pcap
- Analyze the captured file in Wireshark.
Observed Behavior
- Each captured radiotap frame is 8 bytes longer than expected.
- The radiotap header indicates a total length that is 8 bytes larger than it should be.
- Wireshark reports parsing errors for these extra 8 bytes at the end of each frame.
- The extra 8 bytes appear to contain random data.
- For example, in one of the captured beacon frames, at the end of the frame, there is an IEEE 802.11 management frame. The last option tag is unknown, and the length of this option is outside the frame borders. If you cut the last 8 bytes from the tail and fix the frame length in the header, the frame becomes correct.
Expected Behavior
Captured frames should have the correct length without any random data at the end.
Workaround
Manually trimming the last 8 bytes from each frame resolves the parsing issues in Wireshark.
System Information
- Device: Yuncore FAP650
- SoC: Qualcomm IPQ6018
- Driver: ath11k
- Kernel version: 6.6.45
- OpenWrt version: r27140-ccc06f6716 (https://github.com/openwrt/openwrt/commit/ccc06f67168abdff5d842a706a68c6ced6ef750b)
Additional Notes
- This issue affects all captured frames, including beacons.
- The problem seems to be consistent across multiple captures.
- The extra bytes do not appear to contain any meaningful data.
- malformed frame screenshot:
- the same frame fixed screenshot:
Possible Cause
The issue may be related to the mac80211 driver in the kernel. But the other devices with the same mac80211 driver works well. So i think it is related to ath11k code.
Friends, if anyone is familiar with this issue, could you please point me in the right direction for further investigation?
To qualcommax owners: please try to capture wlan interface data in monitor mode on yours devices.