On 19/07/2022 17:03, Adrian Chadd wrote:
Hi!
It's not a hardware bug. Dating back to the original AR5416 11n chip,
most flags aren't valid for subframes in an aggregate. Only the final
frame has valid flags. This was explicitly covered internally way back
when.
Ah, thanks for the
From: Linus Lüssing
AR9003 based wifi chips have a hardware bug, they always report a
channel bandwidth of HT40 for any sub-frame of an aggregate which is
not the last one. Only the last sub-frame has correct channel bandwidth
information.
This can be easily reproduced by setting an ath9k based
From: Linus Lüssing
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.
For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation
From: Linus Lüssing
So far, frames were forwarded regardless of the FCS correctness leading
to userspace applications listening on the monitor mode interface to
receive potentially broken frames, even with the "fcsfail" flag unset.
By default, with the "fcsfail" flag of a mo
On Tue, Nov 05, 2019 at 09:19:20AM -0800, Ben Greear wrote:
> Thanks for adding the counter. Since it us u32, I doubt you need the spin
> lock
> below?
Ok, I can remove the spin-lock.
Just for clarification though, if I recall correctly then an increment operator
is not guaranteed to work
From: Linus Lüssing
So far, frames were forwarded regardless of the FCS correctness leading
to userspace applications listening on the monitor mode interface to
receive potentially broken frames, even with the "fcsfail" flag unset.
By default, with the "fcsfail" flag of a mo
On Fri, Nov 01, 2019 at 08:46:53AM -0700, Ben Greear wrote:
> > diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
> > b/drivers/net/wireless/ath/ath10k/htt_rx.c
> > index 53f1095de8ff..ce0a16ebb8bb 100644
> > --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> > +++
From: Linus Lüssing
So far, frames were forwarded regardless of the FCS correctness leading
to userspace applications listening on the monitor mode interface to
receive potentially broken frames, even with the "fcsfail" flag unset.
By default, with the "fcsfail" flag of a mo
