Re: [PATCH] mac80211: Encrypt "Group addressed privacy" action frames

On 2016年06月18日 18:11, Jouni Malinen wrote: What about RX side? Shouldn't there be a matching change there to enforce use of group addressed privacy for the specific Action categories? Thank you. Yes, RX side modification is needed. I was not aware of it because ping test was OK. Now I

[PATCH] mac80211: Fix mesh estab_plinks counting in STA removal case

If a user space program (e.g., wpa_supplicant) deletes a STA entry that is currently in NL80211_PLINK_ESTAB state, the number of established plinks counter was not decremented and this could result in rejecting new plink establishment before really hitting the real maximum plink limit. For

[PATCH V2 RFC 1/2] brcmfmac: delete interface directly in code that sent fw request

So far when receiving event about in-firmware-interface removal our event worker was notifying listener and afterwards it was removing Linux interface. First of all it was resulting in slightly unexpected order. The listener (del_virtual_intf callback) was (usually) returning with success before

[PATCH V2 RFC 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove" for removing interfaces. Try to use this method on cfg80211 request. In case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this will just result in firmware rejecting command and this won't change any

[PATCH] wlcore: reconfigure sta rates on authorization

Since stations can now be added before association (NL80211_FEATURE_FULL_AP_CLIENT_STATE support), no supported rates are set when the station is added to the fw, resulting in fw recovery. Fix it by first configuring the AP basic rates as the station configured rates (when the station is first

Re: [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

Tim Shepard writes: >> >> You're right that it doesn't check the max. However, this is less of a >> problem now that there is no intermediate queueing in the driver; and >> indeed the utility of haven the qlen_* tunables is somewhat questionable >> with the patch applied: The

Re: [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

> > You're right that it doesn't check the max. However, this is less of a > problem now that there is no intermediate queueing in the driver; and > indeed the utility of haven the qlen_* tunables is somewhat questionable > with the patch applied: The only thing this is going to control is the

Re: [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

Tim Shepard writes: >> +static struct sk_buff * >> +ath_tid_pull(struct ath_atx_tid *tid) >> +{ >> +struct ath_softc *sc = tid->an->sc; >> +struct ieee80211_hw *hw = sc->hw; >> +struct ath_tx_control txctl = { >> +.txq = tid->txq, >> +.sta =