On Tue, 2016-02-23 at 13:12 +0100, Felix Fietkau wrote:
>
> It's initialized to 0 by default, in which case it does not limit the
> A-MSDU size. The driver does not need to set it, but it really
> should.
Right, but this is problematic as Emmanuel had pointed out, when
scaling down you run into p
On Tue, 2016-02-23 at 12:11 +0100, Lorenzo Bianconi wrote:
> Add VHT radiotap parsing support to ieee80211_parse_tx_radiotap().
> That capability has been tested using a d-link dir-860l rev b1
> running OpenWrt trunk and mt76 driver
>
> + VHT rate for the transmission (only for devices without o
On Mon, 2016-02-22 at 14:42 -0800, gree...@candelatech.com wrote:
> From: Ben Greear
>
> ath10k supports VHT on 2.4Ghz band.
It can't. At least not formally, as this sentence is written, since VHT
per the spec requires operating on the 5 GHz band, and it also requires
80 MHz bandwidth which isn'
On Wed, 2016-02-17 at 11:47 +0100, Arend van Spriel wrote:
>
> + * @NL80211_ATTR_BSS_SELECT: nested attribute for driver supporting the
> + * BSS selection feature. When used with %NL80211_CMD_GET_WIPHY it contains
> + * NLA_FLAG type according &enum nl80211_bss_select_attr to indicate what
>
On Tue, 2016-02-23 at 06:18 -0800, Ben Greear wrote:
> [root@ben-ota2 lanforge]# iw phy wiphy0 info
> Wiphy wiphy0
>
> Band 1:
[...]
> VHT Capabilities (0x338001b2):
> Max MPDU length: 11454
> Supported Channel Width: neither 160 nor
On Fri, 2016-02-19 at 11:01 +0100, Janusz Dziedzic wrote:
> HW/driver should set NEED_ALIGNED4_SKBS flag in case
> require aligned skbs to four-byte boundaries.
> This affect only TX direction.
>
> Padding is added after ieee80211_hdr, before IV/LLC.
I'm still not super happy with how invasive th
1):
mac80211: Recalc min chandef when station is associated
Johannes Berg (8):
cfg80211: remove CFG80211_REG_DEBUG
mac80211: document status.freq restrictions
mac80211: refactor HT/VHT to chandef code
mac80211_hwsim: remove shadowing variable
rfkill: disentangle po
On Tue, 2016-02-23 at 15:53 +0100, Felix Fietkau wrote:
> > Perhaps we could live with this being done only for the fast-xmit
> > case?
> I don't think we should pass padded vs non-padded frames depending on
> whether fast-xmit was used. The non-fast-xmit codepath could simply
> do the memmove at
On Tue, 2016-02-23 at 13:43 -0500, Avery Pennarun wrote:
> We're putting my version of the patch into our devices in order to be
> able to try different values and see how it changes the percentage of
> devices with nonzero 'pending' field in agg_status. I'm hoping using
> zero here will result i
On Tue, 2016-02-23 at 16:06 +0100, Arnd Bergmann wrote:
>
> Does rfkill always have a separate device in the Linux driver model?
Yes, the rfkill core code registers and adds one in the rfkill class.
> johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the bo
On Tue, 2016-02-23 at 21:46 +0100, Arend Van Spriel wrote:
>
> > Maybe we should be less specific here regarding the NLA_FLAG and
> > say
> > that it will contain attributes for each, indicating which
> > behaviours
> > are supported, and say there's behaviour-dependent data inside each
> > of
> >
On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote:
> So... you add LED trigger to display the state of the airplane
> mode. Ok, why not.
Yes. However, consider that "the airplane mode" isn't a well-defined
concept; some systems may want to light up that LED even when wifi is
still enabled, si
On Tue, 2016-02-23 at 15:45 +0100, Johannes Berg wrote:
> Hi Dave,
>
> Here's a (first, even? I didn't have much until before the
> conference...) pull request for net-next.
>
Hm, need to withdraw this, sorry about that. There appears to be some
compilation issue that I
On Tue, 2016-02-23 at 22:45 +0100, Pavel Machek wrote:
> Well "the airplane mode" is well defined. It means no intentional
> transmitting at radio frequencies.
>
> The fact that you are allowed to use WIFI on certain flights does not
> change anything.
Nope, not that simple. Pick up any (contemp
On Wed, 2016-02-24 at 11:04 +0100, Arend Van Spriel wrote:
> I actually do not see any NLA_NESTED attributes with an explicit
> length. As you mentioned the nla_parse() of the nested attribute will
> validate the length of the stream so no need to put that in the
> policy.
Right, I think what you
On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote:
> If you want different trigger, implement different trigger. If you
> want to indicate all but wifi, implement all but wifi, and then
> userspace can select it by writing trigger name.
This is still mostly a strawman, since userspace cannot
On Wed, 2016-02-24 at 13:14 +0100, Pavel Machek wrote:
>
> Why would it need to? It could look at default triggers for the led
> if it really wanted to.
And then it needs to change them; if anything goes wrong error recovery
is practically impossible since the trigger information is lost
forever.
On Fri, 2016-02-26 at 16:18 +0800, Fengguang Wu wrote:
>
> > I think this build failure is because mac80211_hwsim is an
> > exception to
> > other wireless drivers and is applied via mac80211-next. Should we
> > add
> > an entry for mac80211_hwsim to MAINTAINERS with the correct git
> > tree? I
>
From: Johannes Berg
Since I maintain this driver as part of mac80211, add it to
the file list for mac80211; this helps submitters send it to
me instead of Kalle and also makes the build robot apply the
patches for it on the right tree for build attempts.
Signed-off-by: Johannes Berg
mesh and mpp path removal function
Ilan Peer (1):
mac80211: Recalc min chandef when station is associated
Johannes Berg (8):
cfg80211: remove CFG80211_REG_DEBUG
mac80211: document status.freq restrictions
mac80211: refactor HT/VHT to chandef code
mac80211_hwsim: re
From: Johannes Berg
Just like for CCMP we need to check that for GCMP the fragments
have PNs that increment by one; the spec was updated to fix this
security issue and now has the following text:
The receiver shall discard MSDUs and MMPDUs whose constituent
MPDU PN values are
On Tue, 2016-03-01 at 00:39 +0200, Jouni Malinen wrote:
> > I agree there is a difference in the logic here,
Gah. I thought I'd reviewed the logic and made sure there's no
difference ... :)
> > thanks for taking the
> > time to point it out so clearly, and sorry for missing this. But AFAIU
> >
On Sun, 2016-02-28 at 20:06 -0500, Bob Copeland wrote:
> In certain cases, the 802.11 mesh pathtable code wants to
> iterate over all of the entries in the forwarding table from
> the receive path, which is inside an RCU read-side critical
> section. Enable walks inside atomic sections by allowing
On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>
> +typedef u64 codel_time_t;
Do we really need this? And if yes, does it have to be in the public
header file? Why a typedef anyway?
> - * @txq_ac_max_pending: maximum number of frames per AC pending in
> all txq
> - * entries for a vif
On Fri, 2016-02-26 at 22:16 +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> Just like for CCMP we need to check that for GCMP the fragments
> have PNs that increment by one; the spec was updated to fix this
> security issue and now has the following text:
>
>
On Tue, 2016-03-01 at 00:29 +0200, Jouni Malinen wrote:
> Public Action frames use special rules for how the BSSID field
> (Address
> 3) is set. A wildcard BSSID is used in cases where the transmitter
> and
> recipient are not members of the same BSS. As such, we need to accept
> Public Action fram
On Wed, 2016-02-24 at 12:07 +0100, Felix Fietkau wrote:
> RTS/CTS needs to be enabled if the rate is a fallback rate *or* if
> it's a dual-stream rate and the sta is in dynamic SMPS mode.
>
Applied, thanks.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
t
On Tue, 2016-03-01 at 17:11 -0500, David Miller wrote:
>
> There was a minor merge conflict with net/mac80211/debugfs.c, take
> a look and send me any fixups necessary.
>
Ah yes, I'd wondered when that change was coming in, but missed that
you had it in net-next now.
Looks good, thanks!
johann
On Thu, 2016-02-25 at 11:24 +0200, Emmanuel Grumbach wrote:
> From: David Spinadel
>
> Allow publishing RRM capabilities for features that are not
> HW dependent.
Actually, come to think of it, why don't we do this in mac80211 rather
than the drivers?
The only capability it requires is insertin
he right tree for it
Felix Fietkau (1):
mac80211: minstrel_ht: fix a logic error in RTS/CTS handling
Johannes Berg (2):
mac80211: check PN correctly for GCMP-encrypted fragmented MPDUs
mac80211_hwsim: treat as part of mac8
On Tue, 2016-02-23 at 20:43 +0200, Dima Krasner wrote:
>
> +#ifdef CONFIG_LIBNL_TINY
> +#define nl_handle nl_sock
[...]
> /* libnl 1.x compatibility code */
> -#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
> +#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) &&
> !defined(CONFIG
On Wed, 2016-03-02 at 14:43 -0500, David Miller wrote:
> From: Bob Copeland
> Date: Wed, 2 Mar 2016 10:09:20 -0500
>
> > In the time since the mesh path table was implemented as an
> > RCU-traversable, dynamically growing hash table, a generic RCU
> > hashtable implementation was added to the ke
On Tue, 2016-02-23 at 15:43 +0100, Lorenzo Bianconi wrote:
> Add VHT radiotap parsing support to ieee80211_parse_tx_radiotap().
> That capability has been tested using a d-link dir-860l rev b1
> running OpenWrt trunk and mt76 driver
>
Applied. In case you didn't see, Sven sent a patch to fix the o
On Wed, 2016-02-24 at 10:28 +0100, Felix Fietkau wrote:
>
> + /*
> + * HT A-MPDU limits maximum MPDU size to 4095 bytes. Since aggregation
> + * sessions are started/stopped without txq flush, use the limit here
> + * to avoid having to de-aggregate later.
> + */
> + if
On Wed, 2016-02-24 at 10:29 +0100, Felix Fietkau wrote:
> + /*
> + * If the rate is slower than single-stream MCS4, limit A-MSDU to usual
> + * data packet size
> + */
> + if (g->duration[rate] > MCS_DURATION(1, 0, 104))
> + return 1500;
> +
> + /*
> + *
On Wed, 2016-02-24 at 11:49 +0200, Emmanuel Grumbach wrote:
> From: Sara Sharon
>
> When HW crypto is used, there's no need for the CCMP/GCMP MIC to
> be available to mac80211, and the hardware might have removed it
> already after checking. The MIC is also useless to have when the
> frame is alr
On Wed, 2016-03-02 at 15:54 +0100, Felix Fietkau wrote:
> Fall back to rate control if the requested bitrate was not found.
>
Applied, thakns.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Wed, 2016-02-24 at 16:25 +0100, Sven Eckelmann wrote:
> Not the internal flags but the radiotap flags are parsed when the
> monitor
> injected frames are prepared for transmission. Thus the documentation
> should only document these.
>
Both applied.
johannes
--
To unsubscribe from this list: s
On Thu, 2016-02-25 at 13:59 +0100, Arend Van Spriel wrote:
> On 25-2-2016 12:32, Arend van Spriel wrote:
> > The enumeration nl80211_band intends to expose the public part of
> > ieee80211_band enumeration. As such it should not be used in the
> > kernel. This patch changes nl80211_band usage to ie
On Fri, 2016-02-26 at 22:12 +0200, Jouni Malinen wrote:
> This allows scans for a specific BSSID to be optimized by the user
> space
> application by requesting the driver to set the Probe Request frame
> BSSID field (Address 3) to the specified BSSID instead of the
> wildcard
> BSSID. This prevent
On Sun, 2016-02-28 at 15:19 +0100, Felix Fietkau wrote:
> Buffered multicast frames must be passed to the driver directly via
> drv_tx instead of going through the txq, otherwise they cannot easily
> be scheduled to be sent after DTIM.
>
Applied.
johannes
--
To unsubscribe from this list: send th
On Thu, 2016-03-03 at 16:03 +0100, Felix Fietkau wrote:
>
> > This isn't *quite* right, since you have to take an 802.11 header
> > (vs.
> > an ethernet header) into account, I think?
> It's only a rough approximation anyway to prevent very large A-MSDUs
> from being created with low rates.
>
Ri
On Sun, 2016-02-28 at 09:35 -0800, Dave Taht wrote:
> On Sun, Feb 28, 2016 at 6:19 AM, Felix Fietkau
> wrote:
> > Buffered multicast frames must be passed to the driver directly via
> > drv_tx instead of going through the txq, otherwise they cannot
> > easily be
> > scheduled to be sent after DTIM
On Sun, 2016-02-28 at 20:03 -0500, Bob Copeland wrote:
> The mesh path and mesh gate hashtables are global, containing
> all of the mpaths for every mesh interface, but the paths are
> all tied logically to a single interface. The common case is
> just a single mesh interface, so optimize for that
On Wed, 2016-03-02 at 10:09 -0500, Bob Copeland wrote:
> In certain cases, the 802.11 mesh pathtable code wants to
> iterate over all of the entries in the forwarding table from
> the receive path, which is inside an RCU read-side critical
> section. Enable walks inside atomic sections by allowing
On Thu, 2016-03-03 at 16:11 +0100, Felix Fietkau wrote:
>
> For my own uses, I'd be perfectly fine with limiting A-MSDU size to
> HT limits even when using VHT - in fact I did that in an early RFC
> patch. I mainly relaxed the limit for VHT based on Emmanuel's
> feedback. I also have doubts about
All three applied, but I had to fix your Fixes tag commit ID, no idea
what that referred to :)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
On Thu, 2016-03-03 at 17:41 +0200, Arik Nemtsov wrote:
> On Thu, Mar 3, 2016 at 5:40 PM, Johannes Berg net> wrote:
> > All three applied, but I had to fix your Fixes tag commit ID, no
> > idea
> > what that referred to :)
>
> Yea I might have taken it from some int
On Wed, 2016-03-02 at 12:36 +, Grumbach, Emmanuel wrote:
> >
> I had the same thinking, but somehow people convinced me that a
> driver may prefer not to advertise this without its explicit
> consent.
So ... What are the arguments? :)
johannes
--
To unsubscribe from this list: send the line
On Wed, 2016-03-02 at 19:38 +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION'
> This flag will be set when drivers can fill rx_duration ( approximate
> total air time(usecs) for unicast data/management
On Wed, 2016-03-02 at 23:46 +0200, Emmanuel Grumbach wrote:
> From: Sara Sharon
>
> Some devices, like iwlwifi, have RSS queues. This may cause a
> situation where a disassociation is handled in control path and
> results in station removal while there are prior RX frames
> that were still not pr
On Wed, 2016-03-02 at 20:37 +0100, Arend van Spriel wrote:
> Introducing a new feature that the driver can use to
> indicate the driver/firmware supports configuration of BSS
> selection criteria upon CONNECT command. This can be useful
> when multiple BSS-es are found belonging to the same ESS,
>
On Thu, 2016-03-03 at 21:30 +0530, Mohammed Shafi Shajakhan wrote:
> [shafi] This is part of the Per Station statistics requirement,
Heh. Whose requirements? :)
> the information from 'iw dev wlan#N station dump' which has
> rx_duration
> field will be used by application assesing the statistics
On Thu, 2016-03-03 at 22:01 +0100, Arend Van Spriel wrote:
>
> On 3-3-2016 16:55, Johannes Berg wrote:
> > On Wed, 2016-03-02 at 20:37 +0100, Arend van Spriel wrote:
> > > Introducing a new feature that the driver can use to
> > > indicate the driver/firmware
On Mon, 2016-03-07 at 21:53 +0530, Mohammed Shafi Shajakhan wrote:
>
> +#define IEEE80211_HT_MCS_NUM 32
> +#define IEEE80211_VHT_MCS_NUM10
> +#define IEEE80211_BW_NUM 4
> +#define IEEE80211_NSS_NUM4
> +#define IEEE80211_GI_NUM 2
> +#defin
On Mon, 2016-03-07 at 16:33 +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION'
> This flag will be set when drivers can fill rx_duration (vendor
> specific total air time(usecs) for data/management frame
On Mon, 2016-03-07 at 12:42 +0530, Vasanthakumar Thiagarajan wrote:
> Especially during off-channel scan user space might be interested
> in probe reponse frames along with beacon to build a list
> of preferred channel and bssid which could be sent to the stations
> around for better spectrum manag
This:
> -#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
> +#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) &&
> !defined(CONFIG_LIBNL_TINY)
> -#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 */
> +#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 && CONFIG_LIBNL_TINY */
can be handled by
On Wed, 2016-03-09 at 05:10 +, Thiagarajan, Vasanthakumar wrote:
> When an user space wants to have control over the duration of off-
> channel (single channel) scan it could use remain-on-channel
> interface instead of trigger_scan to perform off-channel scan. I dont
> think BSS cache will be
On Wed, 2016-03-09 at 12:50 +0530, Mohammed Shafi Shajakhan wrote:
>
> + * @rx_duration: approximate total air time(usecs) for all the
> frames from a
> + * connected client
I don't see why this should be restricted to "connected clients". The
same value could be used for a mesh peer. Or TDLS p
On Wed, 2016-03-09 at 15:08 +0530, Mohammed Shafi Shajakhan wrote:
> [shafi] Please suggest if this is ok ? I will be thankful
> if you can suggest a better one if this is not ok
>
> * @rx_duration: approximate total air time(usecs) for all the
> frames from a peer
>
That seems fine. We should
On Wed, 2016-03-09 at 16:22 +0530, Mohammed Shafi Shajakhan wrote:
>
> [shafi] ath10k implementation is based on PPDU duration calculation
> and it does not includes any IFS duration.
>
> So 'Energy' (time spent by the radio on receiving frames from a
> particular peer) makes more sense right ?
>
On Wed, 2016-03-09 at 22:00 +0530, Mohammed Shafi Shajakhan wrote:
>
> I had started studying(understand) your patch. Please
> let me know if you have already added support for the same
> in userspace as well, we like to use your changes and possibly
> add any changes that addresses rx_stats histo
On Tue, 2016-03-15 at 10:42 +, Roger James wrote:
> ath/ath10k ath/ath9k (both ath9k and ath9k_htc) cw1200
> brcm80211/brcmsmac
>
> All the others seem to be doing things with NL80211_IFTYPE_MONITOR in
> the vif structure. This seems contradictory.
>
You should look into the WANT_MONITOR fl
On Tue, 2016-03-15 at 13:01 +, Roger James wrote:
>
> roger@dragon:~/linux-mainline$ find . -name "*.[ch]" -exec grep -n
> IEEE80211_HW_WANT_MONITOR_VIF {} \; -print
> 1851: * @IEEE80211_HW_WANT_MONITOR_VIF: The driver would like to be
> informed of
> 1928:IEEE80211_HW_WANT_MONITOR_VIF,
On Thu, 2016-03-10 at 10:08 -0800, gree...@candelatech.com wrote:
> From: Ben Greear
>
> ath10k supports VHT on 2.4Ghz band.
I still don't think this is the right thing to do.
Most implementations seem to use the BRCM vendor IE to advertise "VHT"
features on 2.4 GHz, since the spec requires 5 G
On Thu, 2016-03-10 at 09:56 -0800, Ben Greear wrote:
> First, are you proposing that I make a copy of the entire local-
> >hw.wiphy->bands array and store it locally in sdata?
No, I think it should be pointers there, say
sdata->bands[X] pointing to the same thing as local->hw.wiphy->bands[X]
i
On Thu, 2016-03-10 at 09:56 -0800, Ben Greear wrote:
>
> With regard to my original patch, are there any other things that I
> could do to make it more acceptable without making copies of the
> driver data?
>
Oops, saw this too late.
I can't really think of anything that would really make me th
On Tue, 2016-03-15 at 09:10 -0700, Ben Greear wrote:
>
> The logic I wrote is basically exactly this. It uses the configured
> rates to specify which of the hardware's rates are allowed and
> disabled.
>
I understand that. I just take issue with the fact that we have to
sprinkle "magic pixie du
On Wed, 2016-03-16 at 09:53 +, Roger James wrote:
>
> However that only accounts for the ath10k, iwldvm, and iwlmvm
> drivers. I realise that there is a lot of history here, but is what
> the remaining drivers doing in any way deprecated? Also can anyone
> give me a heads up on what the archit
On Thu, 2016-03-17 at 15:41 +0200, Emmanuel Grumbach wrote:
> ifmgd->probe_send_count = 0;
> + sdata->u.mgd.flags &= ~IEEE80211_STA_BEACON_LOSS_REPORTED;
This is very racy, concurrent RX will corrupt the flags value since
this requires a read-modify-write and cannot be done with locking
On Thu, 2016-03-17 at 20:37 +0800, Eva Rachel Retuya wrote:
> Use alloc_workqueue() to allocate the workqueue instead of
> create_singlethread_workqueue() since the latter is deprecated and is
> scheduled for removal.
Scheduled where?
> static void iwl_setup_deferred_work(struct iwl_priv *priv)
From: Johannes Berg
If register_netdevice_notifier() fails (which in practice it can't
right now), we should call unregister_pernet_subsys(). Do that.
Reported-by: Ben Hutchings
Signed-off-by: Johannes Berg
---
net/wireless/wext-core.c | 5 -
1 file changed, 4 insertions(+), 1 del
On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote:
> Fix order of mac80211_rx_flags description to match the enum.
>
> Signed-off-by: Luis de Bethencourt
> ---
> Hi,
>
> I want ahead and fixed the order of the descriptions. checkpatch.pl
> was giving
> a warning to my previous patch a
On Sun, 2016-03-20 at 14:55 -0400, Tejun Heo wrote:
> If everything else is working, I'd be happy to throw in
> WQ_MEM_RECLAIM but I really don't want to add it if it doesn't
> actually achieve the goal. Can a wireless person chime in here?
>
I think for many wireless devices the workqueue, like
On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote:
>
> Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28:
> deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason:
> 3=DEAUTH_LEAVING)
> Mar 25 17:02:05 ath10k.candelatech.com kernel: [ cut here
> ]
> Mar 25 17:
On Wed, 2016-03-09 at 11:29 +0200, Emmanuel Grumbach wrote:
> From: Sara Sharon
>
> Some hardware (iwlwifi an example) de-aggregate AMSDUs and
> copy the IV as is to the generated MPDUs, so the same PN
> appears in multiple packets without being a replay attack.
> Do not increment the PN until al
On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote:
> Looks like rhashtable has too much policy in it to properly deal with
> cases where there are too many hash collisions, so I am going to work
> on reverting it's use in mac80211.
I'm not really all that happy with that approach - can't we fix
On Wed, 2016-03-30 at 21:55 +0800, Herbert Xu wrote:
> Well to start with you should assess whether you really want to
> hash multiple objects with the same key. In particular, can an
> adversary generate a large number of such objects?
No, the only reason this happens is local - if you take the
On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote:
> If someone can fix rhashtable, then great.
> I read some earlier comments [1] back when someone else reported
> similar problems, and the comments seemed to indicate that rhashtable
> was broken in this manner on purpose to protect against has
On Thu, 2016-03-31 at 08:13 -0700, Ben Greear wrote:
>
> I see insertion failure, and then later, if of course fails to delete
> as well since it was never inserted to begin with. There is no good
> way to deal with insertion error, so just need to fix the hashtable.
Oh, that's an oversight in m
From: Johannes Berg
The original hand-implemented hash-table in mac80211 couldn't result
in insertion errors, and while converting to rhashtable I evidently
forgot to check the errors.
This surfaced now only because Ben is adding many identical keys and
that resulted in hidden insertion e
On Thu, 2016-03-31 at 15:50 +0800, Herbert Xu wrote:
> On Thu, Mar 31, 2016 at 09:46:45AM +0200, Johannes Berg wrote:
> >
> >
> > In this case, I think perhaps you can just patch your local system
> > with
> > the many interfaces connecting to the same AP
On Fri, 2016-04-01 at 14:01 +0530, Sunil Shahu wrote:
> Break the loop after matching sectcmd is found. Remove redundant
> variable copying.
>
> Signed-off-by: Sunil Shahu
> ---
> iw.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/iw.c b/iw.c
> index 0f511d9..73ae3
On Fri, 2016-04-01 at 08:46 +0800, Herbert Xu wrote:
> On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote:
> >
> >
> > Does removing this completely disable the "-EEXIST" error? I can't
> > say
> > I fully understand the elasticity
On Sat, 2016-04-02 at 09:46 +0800, Herbert Xu wrote:
> On Fri, Apr 01, 2016 at 11:34:10PM +0200, Johannes Berg wrote:
> >
> >
> > I was thinking about that one - it's not obvious to me from the
> > code
> > how this "explicitly checking for dups" w
On Fri, 2016-04-01 at 14:13 -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> By default, the rhashtable logic will fail to insert
> objects if the key-chains are too long and un-balanced.
>
> In the degenerate case where mac80211 is creating many
> station vdevs connected to the same
On Fri, 2016-03-18 at 16:09 +, Luis de Bethencourt wrote:
> Add documentation for the flag for duplication check.
>
> Fixes the following warning when running make htmldocs:
> warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum
> 'mac80211_rx_flags'
>
Applied, thanks.
johannes
On Fri, 2016-03-18 at 19:23 +, Luis de Bethencourt wrote:
> Commit 976bd9efdae6 ("mac80211: move beacon_loss_count into ifmgd")
> removed the member from the sta_info struct but the description
> stayed
> lingering. Remove it.
>
Also applied.
johannes
--
To unsubscribe from this list: send th
On Thu, 2016-03-17 at 16:51 +0200, Emmanuel Grumbach wrote:
> Frames that are sent between
> ampdu_action(IEEE80211_AMPDU_TX_START) and the move to the
> HT_AGG_STATE_OPERATIONAL state are buffered.
> If we try to start an A-MPDU session while the peer is
> sleeping and polling frames with U-APSD,
On Tue, 2016-03-08 at 13:35 +0200, Emmanuel Grumbach wrote:
> From: Ilan Peer
>
> It is possible that the station is connected to an AP
> with bandwidth of 80+80MHz or 160MHz. In such cases
> there is no need to perform an upgrade as the maximal
> supported bandwidth is 80MHz.
>
> In addition, w
On Thu, 2016-03-17 at 16:51 +0200, Emmanuel Grumbach wrote:
> Since we enqueued the frame that was supposed to be sent
> during the SP, and that frame may very well cary the
> IEEE80211_TX_STATUS_EOSP bit, we may never close the SP
> (WLAN_STA_SP will never be cleared). If that happens, we
> will n
On Thu, 2016-03-03 at 23:25 +0100, Felix Fietkau wrote:
> There were a few issues that were slowing down the process of finding
> the optimal rate, especially on devices with multi-rate retry
> limitations:
>
[...]
applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe li
On Mon, 2016-04-04 at 14:15 -0400, Jeff Mahoney wrote:
> This fixes:
>
> net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used
> uninitialized in this function
>
> target_metric is only consumed when reply = true so no bug exists
> here,
> but gcc doesn't notice that. Initializin
On Wed, 2016-03-09 at 10:08 +0200, Emmanuel Grumbach wrote:
> Allow publishing RRM capabilities for features that are not
> HW dependent.
>
Applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More maj
Both applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dmitrijs,
Thanks for reporting this problem.
> The patch below corrects this problem in kernel space.
I don't think that this is correct, there are four more users of
NETLINK_URELEASE (nfnetlink, NFC), and afaict all of them have the same
bug as nl80211.
Rather than fix all of them, I think
On Sat, 2016-03-19 at 19:59 +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> Remove unused variable in per STA debugfs structure, 'commit
> 34e895075e21
> ("mac80211: allow station add/remove to sleep")' removed the only
> user of
> 'add_has_run'.
>
Applied.
johannes
Hi,
The implementation seems fine now, but I think the commit log needs some work.
> Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION'
I think it'd be worthwhile to describe the attribute a bit more,
including why you're adding it.
> This flag
There's no flag.
> will be se
From: Johannes Berg
According to the spec, VHT doesn't exist in 2.4GHz.
There are vendor extensions to allow a subset of VHT to work
(notably 256-QAM), but since mac80211 doesn't support those
advertising VHT capability on 2.4GHz leads to the behaviour
of reporting VHT capabiliti
1001 - 1100 of 4576 matches
Mail list logo
