Incorrect Rx packet length reported via "tpacket3_hdr->tp_snaplen" (also, awful rx quality, but excellent tx)

[cypher-pnk]

Hello.

Firstly, I'm not sure if the bug I'm reporting is a kernel bug, driver bug or even a hardware bug. The only thing I'm sure about: this is not my application being quirky, but something deep in the system.

• I use the 8814au driver on a Raspberry Pi 4 with Alfa AWUS1900 cards
• 64-bit kernel, 6.6.31+rpt-rpi-v8
• I have downloaded the source recently and compiled it natively on the Raspberry Pi
• card has sufficient power (drawing power from two USB ports)
• my application transmits a high volume of packets (video) in monitor / inject mode
• packets are injected via raw sockets (io vector mechanism)
• packets are captured via raw sockets using this mechanism:

https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt

• I'm using TPACKET_V3 with an RX_RING buffer
• there is a function that does

void scan_rx_block(struct t_netcap_blockdesc *p_block, const int block_num) {

int packets_in_block = p_block->tph1.num_pkts;

// Keep track of the number of total packets captured during this second.
c_total += packets_in_block;

struct tpacket3_hdr *tph3;

tph3 = (struct tpacket3_hdr ) ((uint8_t) p_block + p_block->tph1.offset_to_first_pkt);
// printf("%d ppb\n",packets_in_block);

for (int i = 0; i < packets_in_block; ++i) {

 // Get packet total length
 size_t len = tph3->tp_snaplen;

...and it gets an incorrect value from "tph3->tp_snaplen" only when using the "8814au" driver. I have tested with two other wireless cards and drivers, and those give the correct value. The distorted value given under "8814au" is exactly 4 bytes bigger than the real packet length.

As a side note to anyone interested in the performance of various Wifi hardware: reception quality under Alfa AWUS1900 (this card uses the "8814au" driver) is bloody awful, but transmission power and quality are excellent. This is likely a hardware issue, but I'm noting it just in case because it sticks out like a sore thumb.

I compared the following scenarios:

Alfa AWUS1900 -> Alfa AWUS036NEH-003 = excellent (30/30 frames per second)
Alfa AWUS1900 -> no-name Ralink 5572 from China = exellent (29 fps, very few frame skips)
Alfa AWUS1900 -> Alfa AWUS1900 = bloody awful (10..20 fps, frequent and severe frame drops)
Alfa AWUS036NEH-003 -> Alfa AWUS1900 = bloody awful (10..15 fps, frequent and severe frame drops)
Alfa AWUS036NEH-003 -> Alfa AWUS036NEH-003 = good (24..27 fps, few and mild frame drops)
no-name Ralink 5572 from China -> no-name Ralink 5572 from China = good (25..28 fps, few and mild frame drops)

I have attached a file "wifi-comparison.txt" to this messge.

A legend that may help reading it (all values per second).

FPS = successfully decoded video frames
Nu = null packets
To = total packets
Re = repeat packets (application specific stuff)
Ot = other hosts' packets (decided by examining IEEE802.11 headers)
In = insane packets (application specific stuff)
Ha = hash errors (cryptographic checksum failed)
Pa = packets lost
Fr = fragments lost
OK = successfully arrived

Attachment: wifi_comparison.txt

If I've reported this oddity in the wrong place, I'm very grateful for pointing me towards a better place. :)

The matter is not urgent as I'm researching / comparing a lot of hardware before picking what to run with. If it fails, it fails, but I feel my duty is to help others fix things. :)

[cypher-pnk]

P.S. My signal quality issue was definitely hardware-related and not driver-related because on closer study, my cards using "8814au" have excellent signal quality in the 5.8 GHz band, the problem is limited strictly to the 2.4 GHz band.

The packet length being 4 bytes off is therefore the only issue that remains. I made a configuration option for my software to tolerate it.

[erikarn]

hm, are you seeing 4 extra bytes, or 4 missing bytes?

4 extra bytes could be the FCS? 4 missing bytes, that's another fun one...

[morrownr]

@erikarn @cypher-pnk

FYI: Work on a new driver for the rtl8814au is underway. I expect it to be available for testing at some point in the first half of 2025. It will be added to the rtw88 series of in-kernel drivers. Work will be done at the following site:

https://github.com/lwfinger/rtw88

I will post message here in this repo when the driver is ready for testing. This is an ongoing effort to improve rtw88. Drivers for the rtl8812au and rtl8821/11au chips just went into kernel 6.13. Many improvements to the overall code in rtw88 have gone in this year and performance/stability has been increased greatly.

I post this to let both of you know that I am not ignoring this issue but rather my time is better spent on projects to be get us where we want to be.

FYI: The Main Menu for this site is:

https://github.com/morrownr/USB-WiFi