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.