* Re: [PATCH] ath9k: preserve DFS flags in calcrxfilter
From: Felix Fietkau @ 2011-11-02 13:19 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, ath9k-devel, rodrigue, linville
In-Reply-To: <1320235803-12190-1-git-send-email-zefir.kurtisi@neratec.com>
On 2011-11-02 1:10 PM, Zefir Kurtisi wrote:
> RX filter flags previously set for DFS radar detection were not
> preserved after "ath9k: disable unnecessary PHY error reporting".
>
> This patch ensures that the flags required for DFS support are
> kept set.
>
> Signed-off-by: Zefir Kurtisi<zefir.kurtisi@neratec.com>
I think preserving the existing register values is a bit fragile wrt.
hardware resets, register clobbering, etc.
How about just adding an internal flag or bool in the softc?
- Felix
^ permalink raw reply
* Re: [PATCH] ath9k: preserve DFS flags in calcrxfilter
From: Zefir Kurtisi @ 2011-11-02 16:23 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel, rodrigue, linville
In-Reply-To: <4EB14365.6000505@openwrt.org>
On 11/02/2011 02:19 PM, Felix Fietkau wrote:
> On 2011-11-02 1:10 PM, Zefir Kurtisi wrote:
>> RX filter flags previously set for DFS radar detection were not
>> preserved after "ath9k: disable unnecessary PHY error reporting".
>>
>> This patch ensures that the flags required for DFS support are
>> kept set.
>>
>> Signed-off-by: Zefir Kurtisi<zefir.kurtisi@neratec.com>
> I think preserving the existing register values is a bit fragile wrt. hardware resets, register clobbering, etc.
> How about just adding an internal flag or bool in the softc?
>
> - Felix
Hm, need to dig deeper.
Ideally, the DFS rx filter flags are set at reset along with the channel setup and remain untouched until the chip is stopped (and set-up again).
In fact, currently ath9k_hw_setrxfilter() is called only when the chip is stopped (clearing all flags in ath_stoprecv()) and from ath_opmode_init() and ieee80211_configure_filter() with the flags returned by ath_calcrxfilter().
Since ath_calcrxfilter() provides static initial filter settings for the current opmode, all rx filter flags set internally are reset each time ieee80211_configure_filter() is called.
With your proposal, we need to mirror each rx filter bit set in softc to be reset in ath_calcrxfilter(), right?.
My thinking is, if it is assured that the chip is always reset after a stop, we can ignore potential register clobbering and preserve those bits set in ath_calcrxfilter().
Thanks
Zefir
^ permalink raw reply
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Ben Greear @ 2011-11-02 16:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320220415.3950.1.camel@jlt3.sipsolutions.net>
On 11/02/2011 12:53 AM, Johannes Berg wrote:
> On Fri, 2011-10-28 at 11:55 -0700, Ben Greear wrote:
>
>>> This should be a parameter to connect() and assoc(), not a generic
>>> netdev parameter, since it applies to the connection.
>>>
>>> Also, it would be good to have a capability check for it etc. since a
>>> lot of fullmac drivers will likely never implement this.
>>
>> The existing code always sets the IEEE80211_STA_DISABLE_11N flag in u.mgd if
>> WEP or TKIP is configured, without any capability checks, and my patch
>> sets that flag in the same location.
>>
>> So, maybe it is OK as is?
>>
>> If not, I will add a new capability bit and just enable
>> it in ath9k (and let others enable it in their drivers as they wish).
>
> You misunderstood -- I said fullmac drivers, not differences between
> ath9k, iwlwifi etc. Other cfg80211 drivers, not other mac80211 drivers.
Can you at least point me to some existing code that does a similar
check? I have no idea of what a fullmac driver even does. I can test
and eventually somewhat understand the paths for ath9k, but I have no
ability to test fullmac (as far as I know).
If you don't have time to explain in more detail, then I will just
carry these patches in my own tree. That is a total pain in
the arse when dealing with new netlink commands, but I just do not
have enough understanding of the entire wifi stack to make much
progress with a lot of your suggestions.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Ben Greear @ 2011-11-02 16:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320220577.3950.4.camel@jlt3.sipsolutions.net>
On 11/02/2011 12:56 AM, Johannes Berg wrote:
> On Fri, 2011-10-28 at 09:24 -0700, Ben Greear wrote:
>
>>>> +++ b/net/mac80211/cfg.c
>>>> @@ -57,6 +57,9 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
>>>> struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>>>> int ret;
>>>>
>>>> + if (params->disable_11n != -1)
>>>> + sdata->cfg_disable_11n = params->disable_11n;
>>>
>>> This doesn't seem right -- why change the iface for it? It's a per
>>> connection parameter.
>>
>> I wanted it to be an interface parameter, or at least I think
>> that is what I want.
>
> Why? I'm thinking that it's better as a connection parameter as then
> it's more temporal. I know we have interface parameters like RTS/CTS
> settings etc, but I like connection parameters better as they go away
> with each new connection, so the behaviour is less surprising to most
> users. Imagine your wpa_supplicant crashes, and then the user who was
> restricting it to no-HT starts the regular wpa_supplicant; now his
> interface will be in no-HT until he reboots or figures out the right
> magic to change it. I think that kind of situation is undesirable.
Ok, I will try to figure out how to do this as part of connection.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [wireless-next PATCH v2 1/4] mac80211: Support forcing station to disable 11n.
From: Ben Greear @ 2011-11-02 16:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320220666.3950.6.camel@jlt3.sipsolutions.net>
On 11/02/2011 12:57 AM, Johannes Berg wrote:
> On Fri, 2011-10-28 at 15:21 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This allows a user to configure a wifi station interface
>> to disable 802.11n, even if the AP and NIC supports it.
>
> You really should've waited for the review on v1 to finish -- this v2 is
> worthless. That makes John think that you addressed all review feedback,
> when really we didn't even finish discussing some points; eventually
> that'll just force me to have my own tree so John isn't confused all the
> time.
I explicitly noted in the comments for several of the patches
that I did not address all of your comments. I re-posted because
I thought I could at least fix some of your concerns and hopefully
get the patches closer to right and make further reviews easier.
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [wireless-next PATCH 3/5] wifi: Allow overriding some HT information.
From: Ben Greear @ 2011-11-02 16:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320221630.3950.22.camel@jlt3.sipsolutions.net>
On 11/02/2011 01:13 AM, Johannes Berg wrote:
> On Fri, 2011-10-28 at 09:33 -0700, Ben Greear wrote:
>
>>>> * Allow configuring the mcs (/n) rates available.
>>>> * Allow configuration of MAX-A-MSDU
>>>> * Allow configuration of A-MPDU factor& density.
>>>>
>>>> Users can only remove existing rates. The MSDU and MPDU
>>>> values can be set to any value allowed by the 802.11n
>>>> specification.
>>>
>>> That can't work -- the device might not support it.
>>
>> The device would always support removing rates, right?
>
> No. As I pointed out in another email, you need to think beyond
> mac80211.
>
>> As for the MSDU and MPDU stuff, I would need to add capabilities
>> flags and then enable each driver as they are tested?
>
> No. Neither of these can ever be increased so it's not that simple. And
> making it smaller is always possible since it's just advertising.
> Presumably you do understand the reasons for this advertising/these
> restrictions?
It seems that a driver might default to a mid-range value for the MPDU values
because it is somehow 'better' for whatever reason, and yet it might still
support larger values if the user desires, perhaps because in specific
scenarios larger values are better. Ath9k does set to the max value,
so if we do a per-driver capabilities flag as I did in v2 then we
are safe.
>>> I also don't really like the way you pass in some binary "mask" when
>>> it's not really a binary masking operation.
>>
>> I found the mask to work very well. It's easy enough to
>> deal with in user-space, and easily allows us to add override features
>> (the additional bits to support the MPDU stuff once the
>> HT rates logic was in is a very small bit of code).
>>
>> Otherwise, I'll need to add new netlink commands for each new
>> feature. That is going to bloat hostapd as well as the
>> kernel.
>
> I'm not sure it'll bloat it, but I can live with the binary struct. It
> seems a bit ugly to me but I think it's acceptable. However, you should
> document more clearly what struct it is and how it is defined to work.
> You're also relying on userspace to not do stupid things (otherwise your
> code reads memory out of bounds), this would help:
>
>> /* add attributes here, update the policy in nl80211.c */
I copied some of that code from nl80211_set_station, which appears to
also forget to check the length for the NL80211_ATTR_HT_CAPABILITY
object. Is there some reason why it doesn't need to check, or does
that code need fixing as well?
> Anyway, I'm out of breath. I think this is simply bad implementation&
> execution of your ideas. These are somewhat interesting features and I'm
> willing to accommodate even some of the more esoteric features that most
> people will never use, but I'm quite annoyed by how much of your patches
> I end up doing myself through review.
>
> Please focus more on the quality of your patches in "details" like
> security, API issues, non-mac80211 drivers and even simply logic like
> the A-MSDU thing I just pointed out. I'm spending a disproportionate
> amount of time reviewing your patches over and over again with every
> patchset and am no longer willing to do that.
I listed several thinks that could be changed in the patch description,
and your comment was:
That can't work -- the device might not support it.
Now, how am I supposed to know what you are talking about?
> Obviously we'll still have to discuss things like whether it should be a
> connection or interface parameter -- but I shouldn't have to point out
> trivial security issues -- you should be focusing more on these things
> while writing the code, not after the fact where it's much harder. E.g.
> never ever use nla_data() without validating nla_len() in some way, it
> seems to me that should be completely obvious.
Well, it's more obvious now. Do you also need to check the length when
doing code like this code from nl80211_set_station:
if (info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL])
params.listen_interval =
nla_get_u16(info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL]);
In other words, is it safe to assume you have 16 bits, or could a broken
user-space pass in a single byte and screw this up?
>>>> + memcpy(&ht_cap,&sband->ht_cap, sizeof(ht_cap));
>>>> + /*
>>>> + * This is for an association attempt, and we must
>>>> + * advert at least the first 8 rates, even if we
>>>> + * will later force the rate control to a lower rate.
>>>> + */
>>>> + ieee80211_apply_htcap_overrides(sdata,&ht_cap, 8);
>>>
>>> Yuck, why, why hard-code 8, etc.
>>
>> I can make a define that involves MCS7.
>
> I don't think I understand then why MCSs 0-7 must be supported?
From 20.1.1 of the 802.11n spec:
"An HT non-AP STA shall support all equal modulation (EQM) rates for one spatial stream (MCSs 0 through
7) using 20 MHz channel width. An HT AP shall support all EQM rates for one and two spatial streams
(MCSs 0 through 15) using 20 MHz channel width."
That is why I wrote that code as I did, but perhaps I misunderstand that section of
the docs.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/4] mac80211: QoS multicast frames have No Ack policy
From: Thomas Pedersen @ 2011-11-02 17:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, devel, linville
In-Reply-To: <1320229077.3950.40.camel@jlt3.sipsolutions.net>
On Wed, Nov 2, 2011 at 3:17 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2011-10-28 at 22:05 -0700, Thomas Pedersen wrote:
>> Previously QoS multicast frames had the Normal Acknowledgment QoS
>> control bits set. This would cause broadcast frames to be discarded by
>> peers with which we have a BA session, since their sequence number would
>> fall outside the allowed range. Set No Ack QoS control bits on multicast
>> QoS frames and filter these in de-aggregation code.
>
> I'm not sure why you would attempt to deaggregate broadcast frames but I
> guess mesh is a bit special.
>
>> @@ -770,6 +771,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
>> if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
>> goto dont_reorder;
>>
>> + /* not part of a BA session */
>> + if (!((ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK) ||
>> + (ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)))
>> + goto dont_reorder;
>
> Maybe ack_policy != BA && ack_policy != NORMAl would be easier to read?
OK.
>
>> --- a/net/mac80211/wme.c
>> +++ b/net/mac80211/wme.c
>> @@ -147,7 +147,8 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
>>
>> tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
>>
>> - if (unlikely(sdata->local->wifi_wme_noack_test))
>> + if (unlikely(sdata->local->wifi_wme_noack_test) ||
>> + is_multicast_ether_addr(hdr->addr1))
>> ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
>
> Interestingly, this seems to have been a bug for a long time --
> 7.1.3.5.3 indicates this is supposed to be done.
I'll fix up the other patches as well and resubmit.
Thanks!
Thomas
^ permalink raw reply
* Re: [wireless-next PATCH 3/5] wifi: Allow overriding some HT information.
From: Johannes Berg @ 2011-11-02 17:49 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB176F9.7090304@candelatech.com>
On Wed, 2011-11-02 at 09:59 -0700, Ben Greear wrote:
> > No. Neither of these can ever be increased so it's not that simple. And
> > making it smaller is always possible since it's just advertising.
> > Presumably you do understand the reasons for this advertising/these
> > restrictions?
>
> It seems that a driver might default to a mid-range value for the MPDU values
> because it is somehow 'better' for whatever reason, and yet it might still
> support larger values if the user desires, perhaps because in specific
> scenarios larger values are better. Ath9k does set to the max value,
> so if we do a per-driver capabilities flag as I did in v2 then we
> are safe.
Then the proper way to do that would be to not have a flag, but a max it
can be set to. However, I see no reason it should default to a mid-range
value?! iwlwifi for example needs to allocate enough space but ... I
don't get it. What's wrong with simply not allowing to increase, only
decrease?
> >> /* add attributes here, update the policy in nl80211.c */
>
> I copied some of that code from nl80211_set_station, which appears to
> also forget to check the length for the NL80211_ATTR_HT_CAPABILITY
> object. Is there some reason why it doesn't need to check, or does
> that code need fixing as well?
NL80211_ATTR_HT_CAPABILITY in particular *has* a policy entry.
> Well, it's more obvious now. Do you also need to check the length when
> doing code like this code from nl80211_set_station:
>
> if (info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL])
> params.listen_interval =
> nla_get_u16(info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL]);
>
> In other words, is it safe to assume you have 16 bits, or could a broken
> user-space pass in a single byte and screw this up?
There's the policy that validates it.
> From 20.1.1 of the 802.11n spec:
>
> "An HT non-AP STA shall support all equal modulation (EQM) rates for one spatial stream (MCSs 0 through
> 7) using 20 MHz channel width. An HT AP shall support all EQM rates for one and two spatial streams
> (MCSs 0 through 15) using 20 MHz channel width."
>
> That is why I wrote that code as I did, but perhaps I misunderstand that section of
> the docs.
No, that makes some sense, I wasn't aware of that restriction.
johannes
^ permalink raw reply
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Johannes Berg @ 2011-11-02 17:51 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB17103.70506@candelatech.com>
On Wed, 2011-11-02 at 09:34 -0700, Ben Greear wrote:
> > You misunderstood -- I said fullmac drivers, not differences between
> > ath9k, iwlwifi etc. Other cfg80211 drivers, not other mac80211 drivers.
>
> Can you at least point me to some existing code that does a similar
> check? I have no idea of what a fullmac driver even does. I can test
> and eventually somewhat understand the paths for ath9k, but I have no
> ability to test fullmac (as far as I know).
Well ideally you have two patches -- one for cfg80211, and one for
mac80211. Then you can test the cfg80211 one w/o mac80211 patches, so it
behaves as though it didn't support it, and with the mac80211 patch it
sets the flag to support it. Just think about drivers like ath6kl.
johannes
^ permalink raw reply
* Re: [wireless-next PATCH v2 1/4] mac80211: Support forcing station to disable 11n.
From: Johannes Berg @ 2011-11-02 17:51 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB1726E.5010503@candelatech.com>
On Wed, 2011-11-02 at 09:40 -0700, Ben Greear wrote:
> On 11/02/2011 12:57 AM, Johannes Berg wrote:
> > On Fri, 2011-10-28 at 15:21 -0700, greearb@candelatech.com wrote:
> >> From: Ben Greear<greearb@candelatech.com>
> >>
> >> This allows a user to configure a wifi station interface
> >> to disable 802.11n, even if the AP and NIC supports it.
> >
> > You really should've waited for the review on v1 to finish -- this v2 is
> > worthless. That makes John think that you addressed all review feedback,
> > when really we didn't even finish discussing some points; eventually
> > that'll just force me to have my own tree so John isn't confused all the
> > time.
>
> I explicitly noted in the comments for several of the patches
> that I did not address all of your comments. I re-posted because
> I thought I could at least fix some of your concerns and hopefully
> get the patches closer to right and make further reviews easier.
Ok, fair enough. I just saw them as extra mail and basically didn't even
read them, maybe I should have.
johannes
^ permalink raw reply
* Re: [PATCH 2/4] mac80211: QoS multicast frames have No Ack policy
From: Thomas Pedersen @ 2011-11-02 17:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, devel, linville
In-Reply-To: <CAG6hwVOqyb6Oi63vjD0j6KLAc70cpiWsb9MOR2mZjqPqnVNAcQ@mail.gmail.com>
On Wed, Nov 2, 2011 at 10:35 AM, Thomas Pedersen <thomas@cozybit.com> wrote:
> On Wed, Nov 2, 2011 at 3:17 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Fri, 2011-10-28 at 22:05 -0700, Thomas Pedersen wrote:
>>> Previously QoS multicast frames had the Normal Acknowledgment QoS
>>> control bits set. This would cause broadcast frames to be discarded by
>>> peers with which we have a BA session, since their sequence number would
>>> fall outside the allowed range. Set No Ack QoS control bits on multicast
>>> QoS frames and filter these in de-aggregation code.
>>
>> I'm not sure why you would attempt to deaggregate broadcast frames but I
>> guess mesh is a bit special.
>>
I don't think it's a mesh specific thing, broadcast frames are just
not being sent out as QoS data in the infrastructure case and
therefore not caught by the de-aggregation code. According to 7.2.2,
broadcast and multicast data frames should go out as QoS if all STAs
in the BSS are QoS STAs. I don't know if this really matters in
practice though.
>>> @@ -770,6 +771,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
>>> if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
>>> goto dont_reorder;
>>>
>>> + /* not part of a BA session */
>>> + if (!((ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK) ||
>>> + (ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)))
>>> + goto dont_reorder;
>>
>> Maybe ack_policy != BA && ack_policy != NORMAl would be easier to read?
>
> OK.
>>
>>> --- a/net/mac80211/wme.c
>>> +++ b/net/mac80211/wme.c
>>> @@ -147,7 +147,8 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
>>>
>>> tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
>>>
>>> - if (unlikely(sdata->local->wifi_wme_noack_test))
>>> + if (unlikely(sdata->local->wifi_wme_noack_test) ||
>>> + is_multicast_ether_addr(hdr->addr1))
>>> ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
>>
>> Interestingly, this seems to have been a bug for a long time --
>> 7.1.3.5.3 indicates this is supposed to be done.
>
> I'll fix up the other patches as well and resubmit.
>
> Thanks!
> Thomas
>
^ permalink raw reply
* Re: [wireless-next PATCH 3/5] wifi: Allow overriding some HT information.
From: Ben Greear @ 2011-11-02 18:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320256198.7846.2.camel@jlt3.sipsolutions.net>
On 11/02/2011 10:49 AM, Johannes Berg wrote:
> On Wed, 2011-11-02 at 09:59 -0700, Ben Greear wrote:
>
>>> No. Neither of these can ever be increased so it's not that simple. And
>>> making it smaller is always possible since it's just advertising.
>>> Presumably you do understand the reasons for this advertising/these
>>> restrictions?
>>
>> It seems that a driver might default to a mid-range value for the MPDU values
>> because it is somehow 'better' for whatever reason, and yet it might still
>> support larger values if the user desires, perhaps because in specific
>> scenarios larger values are better. Ath9k does set to the max value,
>> so if we do a per-driver capabilities flag as I did in v2 then we
>> are safe.
>
> Then the proper way to do that would be to not have a flag, but a max it
> can be set to. However, I see no reason it should default to a mid-range
> value?! iwlwifi for example needs to allocate enough space but ... I
> don't get it. What's wrong with simply not allowing to increase, only
> decrease?
Ok, I'll work on allowing the value to only be decreased.
I should be able to compare against whatever the hardware set in
the channel ht-info I think.
>>>> /* add attributes here, update the policy in nl80211.c */
>>
>> I copied some of that code from nl80211_set_station, which appears to
>> also forget to check the length for the NL80211_ATTR_HT_CAPABILITY
>> object. Is there some reason why it doesn't need to check, or does
>> that code need fixing as well?
>
> NL80211_ATTR_HT_CAPABILITY in particular *has* a policy entry.
Ahh, I didn't realize that's what was meant by policy. Mind if
I change that comment to something like what is below?
/* add attributes here, update the nl80211_policy array in nl80211.c */
>> From 20.1.1 of the 802.11n spec:
>>
>> "An HT non-AP STA shall support all equal modulation (EQM) rates for one spatial stream (MCSs 0 through
>> 7) using 20 MHz channel width. An HT AP shall support all EQM rates for one and two spatial streams
>> (MCSs 0 through 15) using 20 MHz channel width."
>>
>> That is why I wrote that code as I did, but perhaps I misunderstand that section of
>> the docs.
>
> No, that makes some sense, I wasn't aware of that restriction.
Well, personally it seems like a lame restriction, and at least hostapd and ath9k will
deal fine with a station advertising less than that, but probably best to
stick with the spec if possible.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* wireless git trees returning to kernel.org
From: John W. Linville @ 2011-11-02 18:09 UTC (permalink / raw)
To: linux-wireless
Cc: David Woodhouse, Stephen Rothwell, David S. Miller, netdev,
linux-kernel
FYI...
I have migrated the wireless git trees back to the kernel.org
infrastructure. As of right now, the trees are identical between
kernel.org and infradead.org. Further updates likely will only go
to kernel.org, so plan accordingly.
The "current" wireless tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
The "next" wireless tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git
The "testing" wireless tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
Please do the needful!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] cfg80211: merge in beacon ies of hidden bss.
From: Dmitry Tarnyagin @ 2011-11-02 18:19 UTC (permalink / raw)
To: linux-wireless
The problem with PSM when a hidden SSID was used was originally
reported by Juuso Oikarinen.
- When generally scanning, the AP is getting a bss entry with
a zero SSID.
- When associationg, a probe-req is sent to the AP with the SSID,
and as a result a probe-responseis received with the hidden
SSID in place. As a consequence, a second bss entry is created
for the AP, now with the real SSID.
- After association, mac80211 executes ieee80211_recalc_ps(),
but does not switch to powersave becuse the beacon-ies are missing.
As result, the STA does not ever enter PSM.
The patch merges in beacon ies of hidden bss from beacon to the probe
response, creating a consistant set of ies in place.
Signed-off-by: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
---
net/wireless/scan.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index dd0d4c5..237e9ed 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -325,8 +325,8 @@ static bool is_mesh(struct cfg80211_bss *a,
sizeof(struct ieee80211_meshconf_ie) - 2) == 0;
}
-static int cmp_bss(struct cfg80211_bss *a,
- struct cfg80211_bss *b)
+static int cmp_bss_core(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
{
int r;
@@ -348,7 +348,15 @@ static int cmp_bss(struct cfg80211_bss *a,
b->len_information_elements);
}
- r = memcmp(a->bssid, b->bssid, ETH_ALEN);
+ return memcmp(a->bssid, b->bssid, ETH_ALEN);
+}
+
+static int cmp_bss(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
+{
+ int r;
+
+ r = cmp_bss_core(a, b);
if (r)
return r;
@@ -359,6 +367,38 @@ static int cmp_bss(struct cfg80211_bss *a,
b->len_information_elements);
}
+static int cmp_hidden_bss(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
+{
+ const u8 *ie1;
+ const u8 *ie2;
+ size_t ielen;
+ int i;
+ int r;
+
+ r = cmp_bss_core(a, b);
+ if (r)
+ return r;
+
+ ie1 = cfg80211_find_ie(WLAN_EID_SSID,
+ a->information_elements,
+ a->len_information_elements);
+ ie2 = cfg80211_find_ie(WLAN_EID_SSID,
+ b->information_elements,
+ b->len_information_elements);
+ if (!ie1 && !ie2)
+ return 0;
+ if (!ie1 || !ie2)
+ return -1;
+
+ ielen = min(ie1[1], ie2[1]);
+ for (i = 0; i < ielen; ++i)
+ if (ie2[i + 2])
+ return -1;
+
+ return ie2[1] - ie1[1];
+}
+
struct cfg80211_bss *cfg80211_get_bss(struct wiphy *wiphy,
struct ieee80211_channel *channel,
const u8 *bssid,
@@ -475,6 +515,50 @@ rb_find_bss(struct cfg80211_registered_device *dev,
}
static struct cfg80211_internal_bss *
+rb_find_hidden_bss(struct cfg80211_registered_device *dev,
+ struct cfg80211_internal_bss *res)
+{
+ struct rb_node *n = dev->bss_tree.rb_node;
+ struct cfg80211_internal_bss *bss;
+ int r;
+
+ while (n) {
+ bss = rb_entry(n, struct cfg80211_internal_bss, rbn);
+ r = cmp_hidden_bss(&res->pub, &bss->pub);
+
+ if (r == 0)
+ return bss;
+ else if (r < 0)
+ n = n->rb_left;
+ else
+ n = n->rb_right;
+ }
+
+ return NULL;
+}
+
+static int
+merge_hidden_ies(struct cfg80211_internal_bss *res,
+ struct cfg80211_internal_bss *hidden)
+{
+ if (unlikely(res->pub.beacon_ies))
+ return -EALREADY;
+ if (WARN_ON(!hidden->pub.beacon_ies))
+ return -EINVAL;
+
+ res->pub.beacon_ies = kmalloc(hidden->pub.len_beacon_ies, GFP_ATOMIC);
+ if (unlikely(!res->pub.beacon_ies))
+ return -ENOMEM;
+
+ res->beacon_ies_allocated = true;
+ res->pub.len_beacon_ies = hidden->pub.len_beacon_ies;
+ memcpy(res->pub.beacon_ies, hidden->pub.beacon_ies,
+ res->pub.len_beacon_ies);
+
+ return 0;
+}
+
+static struct cfg80211_internal_bss *
cfg80211_bss_update(struct cfg80211_registered_device *dev,
struct cfg80211_internal_bss *res)
{
@@ -494,6 +578,13 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
spin_lock_bh(&dev->bss_lock);
found = rb_find_bss(dev, res);
+ if (!found) {
+ struct cfg80211_internal_bss *hidden;
+
+ hidden = rb_find_hidden_bss(dev, res);
+ if (hidden)
+ merge_hidden_ies(res, hidden);
+ }
if (found) {
found->pub.beacon_interval = res->pub.beacon_interval;
--
With best regards,
Dmitry Tarnyagin
^ permalink raw reply related
* Compat-wireless release for 2011-11-02 is baked
From: Compat-wireless cronjob account @ 2011-11-02 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814862 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3523 - % of code consists of backport work
^ permalink raw reply
* [PATCH v3 1/4] mac80211: Avoid filling up mesh preq queue with redundant requests
From: Thomas Pedersen @ 2011-11-02 19:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Javier Cardona, johannes, linville
From: Javier Cardona <javier@cozybit.com>
Don't accept redundant PREQs for a given destination. This fixes a
problem under high load:
kernel: [20386.250913] mesh_queue_preq: 235 callbacks suppressed
kernel: [20386.253335] Mesh HWMP (mesh0): PREQ node queue full
kernel: [20386.253352] Mesh HWMP (mesh0): PREQ node queue full
(...)
The 802.11s protocol has a provision to limit the rate of path requests
(PREQs) are transmitted (dot11MeshHWMPpreqMinInterval) but there was no
limit on the rate at which PREQs were being queued up. There is a valid
reason for queuing PREQs: this way we can even out PREQ bursts. But
queueing multiple PREQs for the same destination is useless.
Reported-by: Pedro Larbig <pedro.larbig@carhs.de>
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
v3:
move mpath flag update inside state_lock (Johannes)
net/mac80211/mesh.h | 3 +++
net/mac80211/mesh_hwmp.c | 15 +++++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 8c00e2d..b3745e8 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -31,6 +31,8 @@
* @MESH_PATH_FIXED: the mesh path has been manually set and should not be
* modified
* @MESH_PATH_RESOLVED: the mesh path can has been resolved
+ * @MESH_PATH_REQ_QUEUED: there is an unsent path request for this destination
+ * already queued up, waiting for the discovery process to start.
*
* MESH_PATH_RESOLVED is used by the mesh path timer to
* decide when to stop or cancel the mesh path discovery.
@@ -41,6 +43,7 @@ enum mesh_path_flags {
MESH_PATH_SN_VALID = BIT(2),
MESH_PATH_FIXED = BIT(3),
MESH_PATH_RESOLVED = BIT(4),
+ MESH_PATH_REQ_QUEUED = BIT(5),
};
/**
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 9a1f8bb..b22b223 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -867,9 +867,19 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
return;
}
+ spin_lock_bh(&mpath->state_lock);
+ if (mpath->flags & MESH_PATH_REQ_QUEUED) {
+ spin_unlock_bh(&mpath->state_lock);
+ spin_unlock_bh(&ifmsh->mesh_preq_queue_lock);
+ return;
+ }
+
memcpy(preq_node->dst, mpath->dst, ETH_ALEN);
preq_node->flags = flags;
+ mpath->flags |= MESH_PATH_REQ_QUEUED;
+ spin_unlock_bh(&mpath->state_lock);
+
list_add_tail(&preq_node->list, &ifmsh->preq_queue.list);
++ifmsh->preq_queue_len;
spin_unlock_bh(&ifmsh->mesh_preq_queue_lock);
@@ -921,6 +931,7 @@ void mesh_path_start_discovery(struct ieee80211_sub_if_data *sdata)
goto enddiscovery;
spin_lock_bh(&mpath->state_lock);
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
if (preq_node->flags & PREQ_Q_F_START) {
if (mpath->flags & MESH_PATH_RESOLVING) {
spin_unlock_bh(&mpath->state_lock);
@@ -1028,8 +1039,7 @@ int mesh_nexthop_lookup(struct sk_buff *skb,
mesh_queue_preq(mpath, PREQ_Q_F_START);
}
- if (skb_queue_len(&mpath->frame_queue) >=
- MESH_FRAME_QUEUE_LEN)
+ if (skb_queue_len(&mpath->frame_queue) >= MESH_FRAME_QUEUE_LEN)
skb_to_free = skb_dequeue(&mpath->frame_queue);
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
@@ -1061,6 +1071,7 @@ void mesh_path_timer(unsigned long data)
} else if (mpath->discovery_retries < max_preq_retries(sdata)) {
++mpath->discovery_retries;
mpath->discovery_timeout *= 2;
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
spin_unlock_bh(&mpath->state_lock);
mesh_queue_preq(mpath, 0);
} else {
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 2/4] mac80211: QoS multicast frames have No Ack policy
From: Thomas Pedersen @ 2011-11-02 19:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1320262047-5389-1-git-send-email-thomas@cozybit.com>
Previously QoS multicast frames had the Normal Acknowledgment QoS
control bits set. This would cause broadcast frames to be discarded by
peers with which we have a BA session, since their sequence number would
fall outside the allowed range. Set No Ack QoS control bits on multicast
QoS frames and filter these in de-aggregation code.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
v2: Use proper QoS Ack Policy ctl field mask (Christian)
v3: Clean up conditional (Johannes)
include/linux/ieee80211.h | 1 +
net/mac80211/rx.c | 9 ++++++++-
net/mac80211/wme.c | 3 ++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 48363c3..bc61e69 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -128,6 +128,7 @@
#define IEEE80211_QOS_CTL_ACK_POLICY_NOACK 0x0020
#define IEEE80211_QOS_CTL_ACK_POLICY_NO_EXPL 0x0040
#define IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK 0x0060
+#define IEEE80211_QOS_CTL_ACK_POLICY_MASK 0x0060
/* A-MSDU 802.11n */
#define IEEE80211_QOS_CTL_A_MSDU_PRESENT 0x0080
/* Mesh Control 802.11s */
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b867bd5..bbe7b50 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -747,7 +747,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
struct sta_info *sta = rx->sta;
struct tid_ampdu_rx *tid_agg_rx;
u16 sc;
- int tid;
+ u8 tid, ack_policy;
if (!ieee80211_is_data_qos(hdr->frame_control))
goto dont_reorder;
@@ -760,6 +760,8 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
if (!sta)
goto dont_reorder;
+ ack_policy = *ieee80211_get_qos_ctl(hdr) &
+ IEEE80211_QOS_CTL_ACK_POLICY_MASK;
tid = *ieee80211_get_qos_ctl(hdr) & IEEE80211_QOS_CTL_TID_MASK;
tid_agg_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
@@ -770,6 +772,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
goto dont_reorder;
+ /* not part of a BA session */
+ if (ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK &&
+ ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)
+ goto dont_reorder;
+
/* new, potentially un-ordered, ampdu frame - process it */
/* reset session timer */
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index fd52e69..a440a4a 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -147,7 +147,8 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- if (unlikely(sdata->local->wifi_wme_noack_test))
+ if (unlikely(sdata->local->wifi_wme_noack_test) ||
+ is_multicast_ether_addr(hdr->addr1))
ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
/* qos header is 2 bytes */
*p++ = ack_policy | tid;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 3/4] mac80211: check if frame is really part of this BA
From: Thomas Pedersen @ 2011-11-02 19:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1320262047-5389-1-git-send-email-thomas@cozybit.com>
There was an an implicit assumption that any QoS data frame received
from a STA/TID with an active BA session was sent to this vif as part of
a BA. This is not true if IFF_PROMISC is enabled and the frame was
destined for a different peer, for example. Don't treat these frames as
part of a BA from the sending STA.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
v3: use RX_RA_MATCH instead of checking the address directly (Johannes)
net/mac80211/rx.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bbe7b50..45ace14 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -744,6 +744,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
struct ieee80211_local *local = rx->local;
struct ieee80211_hw *hw = &local->hw;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
struct sta_info *sta = rx->sta;
struct tid_ampdu_rx *tid_agg_rx;
u16 sc;
@@ -777,6 +778,10 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)
goto dont_reorder;
+ /* not actually part of this BA session */
+ if (!(status->rx_flags & IEEE80211_RX_RA_MATCH))
+ goto dont_reorder;
+
/* new, potentially un-ordered, ampdu frame - process it */
/* reset session timer */
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 4/4] mac80211: Populate QoS header on mesh frames sent to gates.
From: Thomas Pedersen @ 2011-11-02 19:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Javier Cardona, johannes, linville
In-Reply-To: <1320262047-5389-1-git-send-email-thomas@cozybit.com>
From: Javier Cardona <javier@cozybit.com>
Also set correct skb queue mapping once next hop is known, and set
txinfo jiffies when forwarding.
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
net/mac80211/mesh_hwmp.c | 5 ++++-
net/mac80211/mesh_pathtbl.c | 5 +++++
net/mac80211/rx.c | 8 +++++---
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index b22b223..c4d8efe 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1028,8 +1028,11 @@ int mesh_nexthop_lookup(struct sk_buff *skb,
PREQ_Q_F_START | PREQ_Q_F_REFRESH);
}
next_hop = rcu_dereference(mpath->next_hop);
- if (next_hop)
+ if (next_hop) {
memcpy(hdr->addr1, next_hop->sta.addr, ETH_ALEN);
+ skb_set_queue_mapping(skb,
+ ieee80211_select_queue(sdata, skb));
+ }
else
err = -ENOENT;
} else {
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 332b5ff1..9d2f55f 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -270,6 +270,11 @@ static void prepare_for_gate(struct sk_buff *skb, char *dst_addr,
memcpy(hdr->addr1, next_hop, ETH_ALEN);
rcu_read_unlock();
memcpy(hdr->addr3, dst_addr, ETH_ALEN);
+
+ /* once next hop is set we can set qos header */
+ skb_set_queue_mapping(skb,
+ ieee80211_select_queue(gate_mpath->sdata, skb));
+ ieee80211_set_qos_hdr(gate_mpath->sdata, skb);
}
/**
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 45ace14..302c866 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1965,12 +1965,10 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
memset(info, 0, sizeof(*info));
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = &rx->sdata->vif;
+ info->control.jiffies = jiffies;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(&sdata->u.mesh,
fwded_mcast);
- skb_set_queue_mapping(fwd_skb,
- ieee80211_select_queue(sdata, fwd_skb));
- ieee80211_set_qos_hdr(sdata, fwd_skb);
} else {
int err;
/*
@@ -1991,6 +1989,10 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
}
IEEE80211_IFSTA_MESH_CTR_INC(&sdata->u.mesh,
fwded_frames);
+
+ /* next hop is now known, update the queue mapping */
+ skb_set_queue_mapping(fwd_skb,
+ ieee80211_select_queue(sdata, fwd_skb));
ieee80211_add_pending_skb(local, fwd_skb);
}
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 3.1] iwlwifi: remove un-needed out_iounmap label
From: John W. Linville @ 2011-11-02 19:44 UTC (permalink / raw)
To: Wey-Yi Guy; +Cc: linux-wireless
In-Reply-To: <1319765778-8868-1-git-send-email-wey-yi.w.guy@intel.com>
On Thu, Oct 27, 2011 at 06:36:18PM -0700, Wey-Yi Guy wrote:
> out_iounmap is no longer used, remove it
>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
> apply this patch after "iwlwifi-allow-pci_enable_msi-fail.patch"
FWIW, I combined this patch with the earlier one.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 3.1] iwlwifi: remove un-needed out_iounmap label
From: wwguy @ 2011-11-02 19:51 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20111102194433.GA16597@tuxdriver.com>
On Wed, 2011-11-02 at 12:44 -0700, John W. Linville wrote:
> On Thu, Oct 27, 2011 at 06:36:18PM -0700, Wey-Yi Guy wrote:
> > out_iounmap is no longer used, remove it
> >
> > Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> > ---
> > apply this patch after "iwlwifi-allow-pci_enable_msi-fail.patch"
>
> FWIW, I combined this patch with the earlier one.
>
thank you, should do that at the first place :-)
Wey
^ permalink raw reply
* [PATCH] ieee80211: Define cipher suite selector for WPI-SMS4
From: Jouni Malinen @ 2011-11-02 21:34 UTC (permalink / raw)
To: John W. Linville, Johannes Berg; +Cc: linux-wireless
This value is used for WPI-SMS4 in ISO/IEC JTC 1 N 9880.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/linux/ieee80211.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 48363c3..80cba03 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1552,6 +1552,8 @@ enum ieee80211_sa_query_action {
#define WLAN_CIPHER_SUITE_WEP104 0x000FAC05
#define WLAN_CIPHER_SUITE_AES_CMAC 0x000FAC06
+#define WLAN_CIPHER_SUITE_SMS4 0x00147201
+
/* AKM suite selectors */
#define WLAN_AKM_SUITE_8021X 0x000FAC01
#define WLAN_AKM_SUITE_PSK 0x000FAC02
--
1.7.4.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* [PATCH] nl80211: Increase maximum NL80211_ATTR_KEY_SEQ length to 16
From: Jouni Malinen @ 2011-11-02 21:36 UTC (permalink / raw)
To: John W. Linville, Johannes Berg; +Cc: linux-wireless
WPI-SMS4 uses 16-octet PN field, so we need to allow longer key
sequence values to be configured.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
net/wireless/nl80211.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 48260c2..09fe0bf 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -98,7 +98,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_KEY_IDX] = { .type = NLA_U8 },
[NL80211_ATTR_KEY_CIPHER] = { .type = NLA_U32 },
[NL80211_ATTR_KEY_DEFAULT] = { .type = NLA_FLAG },
- [NL80211_ATTR_KEY_SEQ] = { .type = NLA_BINARY, .len = 8 },
+ [NL80211_ATTR_KEY_SEQ] = { .type = NLA_BINARY, .len = 16 },
[NL80211_ATTR_KEY_TYPE] = { .type = NLA_U32 },
[NL80211_ATTR_BEACON_INTERVAL] = { .type = NLA_U32 },
@@ -204,7 +204,7 @@ static const struct nla_policy nl80211_key_policy[NL80211_KEY_MAX + 1] = {
[NL80211_KEY_DATA] = { .type = NLA_BINARY, .len = WLAN_MAX_KEY_LEN },
[NL80211_KEY_IDX] = { .type = NLA_U8 },
[NL80211_KEY_CIPHER] = { .type = NLA_U32 },
- [NL80211_KEY_SEQ] = { .type = NLA_BINARY, .len = 8 },
+ [NL80211_KEY_SEQ] = { .type = NLA_BINARY, .len = 16 },
[NL80211_KEY_DEFAULT] = { .type = NLA_FLAG },
[NL80211_KEY_DEFAULT_MGMT] = { .type = NLA_FLAG },
[NL80211_KEY_TYPE] = { .type = NLA_U32 },
--
1.7.4.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* [PATCH 2/3] ath6kl: Fix key configuration to copy at most seq_len from seq
From: Jouni Malinen @ 2011-11-02 21:45 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
There is no guarantee on the caller using 8-octet buffer for
key->seq, so better follow the key->seq_len parameter on figuring
out how many octets to copy.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 8 +++++---
drivers/net/wireless/ath/ath6kl/main.c | 5 +++--
drivers/net/wireless/ath/ath6kl/wmi.c | 7 ++++---
drivers/net/wireless/ath/ath6kl/wmi.h | 3 ++-
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 6aff8be..3b9511a 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -500,7 +500,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
vif->prwise_crypto,
GROUP_USAGE | TX_USAGE,
key->key_len,
- NULL,
+ NULL, 0,
key->key, KEY_OP_INIT_VAL, NULL,
NO_SYNC_WMIFLAG);
}
@@ -1014,7 +1014,8 @@ static int ath6kl_cfg80211_add_key(struct wiphy *wiphy, struct net_device *ndev,
status = ath6kl_wmi_addkey_cmd(ar->wmi, vif->fw_vif_idx,
vif->def_txkey_index,
key_type, key_usage, key->key_len,
- key->seq, key->key, KEY_OP_INIT_VAL,
+ key->seq, key->seq_len, key->key,
+ KEY_OP_INIT_VAL,
(u8 *) mac_addr, SYNC_BOTH_WMIFLAG);
if (status)
@@ -1134,7 +1135,8 @@ static int ath6kl_cfg80211_set_default_key(struct wiphy *wiphy,
status = ath6kl_wmi_addkey_cmd(ar->wmi, vif->fw_vif_idx,
vif->def_txkey_index,
key_type, key_usage,
- key->key_len, key->seq, key->key,
+ key->key_len, key->seq, key->seq_len,
+ key->key,
KEY_OP_INIT_VAL, NULL,
SYNC_BOTH_WMIFLAG);
if (status)
diff --git a/drivers/net/wireless/ath/ath6kl/main.c b/drivers/net/wireless/ath/ath6kl/main.c
index f9410e4..a800837 100644
--- a/drivers/net/wireless/ath/ath6kl/main.c
+++ b/drivers/net/wireless/ath/ath6kl/main.c
@@ -442,7 +442,7 @@ static void ath6kl_install_static_wep_keys(struct ath6kl_vif *vif)
WEP_CRYPT,
keyusage,
vif->wep_key_list[index].key_len,
- NULL,
+ NULL, 0,
vif->wep_key_list[index].key,
KEY_OP_INIT_VAL, NULL,
NO_SYNC_WMIFLAG);
@@ -477,7 +477,8 @@ void ath6kl_connect_ap_mode_bss(struct ath6kl_vif *vif, u16 channel)
memset(key_rsc, 0, sizeof(key_rsc));
res = ath6kl_wmi_addkey_cmd(
ar->wmi, vif->fw_vif_idx, ik->key_index, ik->key_type,
- GROUP_USAGE, ik->key_len, key_rsc, ik->key,
+ GROUP_USAGE, ik->key_len, key_rsc, ATH6KL_KEY_SEQ_LEN,
+ ik->key,
KEY_OP_INIT_VAL, NULL, SYNC_BOTH_WMIFLAG);
if (res) {
ath6kl_dbg(ATH6KL_DBG_WLAN_CFG, "Delayed "
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
index ece67a5..612326d 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -2000,7 +2000,8 @@ int ath6kl_wmi_disctimeout_cmd(struct wmi *wmi, u8 if_idx, u8 timeout)
int ath6kl_wmi_addkey_cmd(struct wmi *wmi, u8 if_idx, u8 key_index,
enum crypto_type key_type,
u8 key_usage, u8 key_len,
- u8 *key_rsc, u8 *key_material,
+ u8 *key_rsc, unsigned int key_rsc_len,
+ u8 *key_material,
u8 key_op_ctrl, u8 *mac_addr,
enum wmi_sync_flag sync_flag)
{
@@ -2013,7 +2014,7 @@ int ath6kl_wmi_addkey_cmd(struct wmi *wmi, u8 if_idx, u8 key_index,
key_index, key_type, key_usage, key_len, key_op_ctrl);
if ((key_index > WMI_MAX_KEY_INDEX) || (key_len > WMI_MAX_KEY_LEN) ||
- (key_material == NULL))
+ (key_material == NULL) || key_rsc_len > 8)
return -EINVAL;
if ((WEP_CRYPT != key_type) && (NULL == key_rsc))
@@ -2031,7 +2032,7 @@ int ath6kl_wmi_addkey_cmd(struct wmi *wmi, u8 if_idx, u8 key_index,
memcpy(cmd->key, key_material, key_len);
if (key_rsc != NULL)
- memcpy(cmd->key_rsc, key_rsc, sizeof(cmd->key_rsc));
+ memcpy(cmd->key_rsc, key_rsc, key_rsc_len);
cmd->key_op_ctrl = key_op_ctrl;
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.h b/drivers/net/wireless/ath/ath6kl/wmi.h
index c626c1e..1d458f0 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.h
+++ b/drivers/net/wireless/ath/ath6kl/wmi.h
@@ -2253,7 +2253,8 @@ int ath6kl_wmi_get_stats_cmd(struct wmi *wmi, u8 if_idx);
int ath6kl_wmi_addkey_cmd(struct wmi *wmi, u8 if_idx, u8 key_index,
enum crypto_type key_type,
u8 key_usage, u8 key_len,
- u8 *key_rsc, u8 *key_material,
+ u8 *key_rsc, unsigned int key_rsc_len,
+ u8 *key_material,
u8 key_op_ctrl, u8 *mac_addr,
enum wmi_sync_flag sync_flag);
int ath6kl_wmi_add_krk_cmd(struct wmi *wmi, u8 if_idx, u8 *krk);
--
1.7.4.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* [PATCH] ath6kl: Remove unused WMI crypto defines
From: Jouni Malinen @ 2011-11-02 21:44 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/wmi.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.h b/drivers/net/wireless/ath/ath6kl/wmi.h
index cf0462a..c626c1e 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.h
+++ b/drivers/net/wireless/ath/ath6kl/wmi.h
@@ -585,9 +585,6 @@ enum auth_mode {
WPA2_AUTH_CCKM = 0x40,
};
-#define WMI_MIN_CRYPTO_TYPE NONE_CRYPT
-#define WMI_MAX_CRYPTO_TYPE (AES_CRYPT + 1)
-
#define WMI_MIN_KEY_INDEX 0
#define WMI_MAX_KEY_INDEX 3
--
1.7.4.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox