On 2018/06/25 10:10, Bob Copeland wrote:> The latter bit is actually
reserved for mesh BSSes
according to Table 9-168 in 802.11-2016, so in fact it should not
be set.
Good catch !
Indeed the bit is reserved at non-AP case.
Reviewed-by: Masashi Honma
On 2018/06/25 10:10, Bob Copeland wrote:
The latter bit is actually reserved for mesh BSSes
according to Table 9-168 in 802.11-2016, so in fact it should not
be set.
Good catch !
Indeed the bit is reserved at non-AP case.
Reviewed-by: Masashi Honma
On Sun, 24 Jun 2018 at 13:48, Rafał Miłecki wrote:
> On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
> wrote:
> > Here a couple of patches in preparation of monitor mode support. It
> > is mostly about querying firmware for support. While at it I stumbled
> > upon the fact that 160MHz was not comp
Commit 9757235f451c, "nl80211: correct checks for
NL80211_MESHCONF_HT_OPMODE value") relaxed the range for the HT
operation field in meshconf, while also adding checks requiring
the non-greenfield and non-ht-sta bits to be set in certain
circumstances. The latter bit is actually reserved for mesh
From: Rafał Miłecki
Many/most of firmwares support creating monitor interface but only the
most recent ones explicitly /announce/ it using a "monitor" entry in the
list of capabilities.
Check for that entry and store internally info about monitor mode
support using a new feature flag. Once we so
From: Rafał Miłecki
New Broadcom firmwares mark monitor mode packets using a newly defined
bit in the flags field. Use it to filter them out and pass to the
monitor interface. These defines were found in bcmmsgbuf.h from SDK.
As not every firmware generates radiotap header this commit introduces
From: Rafał Miłecki
Depending on used build-time options some firmwares may already include
radiotap header in passed monitor frames. Add a new feature flag to
store info about it. It's needed for proper handling of received frames
before passing them up.
Signed-off-by: Rafał Miłecki
Signed-off
Stanislaw Gruszka wrote:
> It turned out that we can run calibration without already received
> frames with RSSI data. In such case just don't update AGC register
> and don't print the warning.
>
> Fixes: b305a6ab0247 ("mt7601u: use EWMA to calculate avg_rssi")
> Reported-by: Adam Borowski
> Si
Ganapathi Bhat wrote:
> This reverts commit b817047ae70c0bd67b677b65d0d69d72cd6e9728.
>
> We have a better fix for this issue, which will be sent on top
> of this revert.
>
> Signed-off-by: Ganapathi Bhat
2 patches applied to wireless-drivers.git, thanks.
7e58e741c001 Revert "mwifiex: handle
Ping-Ke Shih wrote:
> From: Ping-Ke Shih
>
> When connecting to AP, mac80211 asks driver to enter and leave PS quickly,
> but driver deinit doesn't wait for delayed work complete when entering PS,
> then driver reinit procedure and delay work are running simultaneously.
> This will cause unpred
On Fri, 22 Jun 2018 at 20:59, Arend van Spriel
wrote:
> On 6/19/2018 10:25 PM, Rafał Miłecki wrote:
> > On 2018-06-19 22:01, Arend van Spriel wrote:
> >> On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
> >>> From: Rafał Miłecki
> >>>
> >>> After a bit long discussions in various e-mail threads I'm com
On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
wrote:
> Firmwares may not provide all monitor mode features in the "cap" iovar.
> For those this fallback mechanism uses "sta_monitor" iovar. If firmware
> is compiled with stamon, this iovar will fail with BCME_NOTUP; Otherwise
> it fails with BCME_
On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
wrote:
> Here a couple of patches in preparation of monitor mode support. It
> is mostly about querying firmware for support. While at it I stumbled
> upon the fact that 160MHz was not completely implemented in the driver
> so there is a patch for tha
13 matches
Mail list logo
