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

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. :)

morrownr / 8814au

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