* Re: I always need a miracle to connect with iwlwifi
From: Krishna Chaitanya @ 2013-10-28 11:00 UTC (permalink / raw)
To: Felipe Contreras
Cc: Oleksij Rempel, linux-wireless Mailing List, ilw,
hostap@lists.shmoo.com
In-Reply-To: <CAMP44s2G63ptScncpPE0ercLY0fT7q0RAvSO6ROyMxm_jLRYXA@mail.gmail.com>
On Mon, Oct 28, 2013 at 3:07 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>> Looks like there is "maximum clients" feature is enabled in the AP, most AP's
>> send deauth for Auth/Assoc Request but some AP's silently discard the
>> Assoc Request.
>>
>> That explains why it works after reboot/adhoc mode. Try increasing the
>> number if thats the case.
>
> Then why am I able to connect from my phone, other machines, and in
> this machine with Windows 7?
>
So lets say "max clients=5" and first all of your devices except the
linux connec
to the AP, then they have no issues connecting. Now if the linux is
the 6th device
then it might have trouble connecting to the AP?? Its possible.
^ permalink raw reply
* Re: [RFC] carl9170: new firmware for linux-firmware.git
From: Rick Farina @ 2013-10-28 12:46 UTC (permalink / raw)
To: Christian Lamparter, Ben Hutchings; +Cc: linux-wireless
In-Reply-To: <1542665.mhS5oZO9DU@debian64>
On 10/25/2013 07:15 PM, Christian Lamparter wrote:
> Hi Ben,
>
> I'm currently updating the carl9170 firmware to the latest
> version (1.9.9). I've already pushed out the sources and
> updated the binaries over at our wiki (for the last time,
> all future update will be via linux-firmware.git).
>
> Now, the last item on my check off list is:
> [ ] new firmware for linux-firmware.git
>
> Last time - when this topic came up - we had a short brainstorm
> about how to handle updates in the future:
> <http://marc.info/?l=linux-wireless&m=136115736909708>
>
> So, I've now prepared some options:
>
> 1. Reorganize carl9170 by creating a new subdirectory "carl9170"
> and move everything in it.
> * A carl9170fw-x.y.z.tar.xz with the source is generated for
> each release and placed under carl9170/source/.
>
> * new firmware binaries are placed in carl9170/.
> (The firmware file name will include the version e.g.
> carl9170-1.9.9.fw, it won't clash with a previous release.)
>
> * A symlink from the linux-firmware.git root to the latest
> carl9170-1.fw in the carl9170 subfolder is added/updated for
> each release.
Why do we need multiple files at all? Why do they all need to be named
carl9170-1.fw? imho if the files are compatible then we only need one,
and if they are not compatible then it is insane that they are all
recognized as "carl9170-1.fw" as that makes it impossible for a user to
know "which carl9170-1.fw" they need for a given kernel.
Thanks,
Zero
>
> For a preview see: [1]
> 116 files changed, 3 insertions(+), 26313 deletions(-)
>
> 2. Simply replace code and firmware binary
> * The code is simply dumped from the carl9170 firmware repository
> into the existing carl9170fw directory.
>
> * The old firmware binary "carl9170-1.fw" file is replaced by the
> new version.
>
> For a preview see: [2]
> 70 files changed, 2479 insertions(+), 4560 deletions(-)
>
> I would prefer to go with option 1 and move everything into a carl9170
> subdirectory. This way has the advantage that we can have multiple
> firmware binaries and sources coexisting in one place. However, I'm
> also aware of the additional "space and bandwidth" cost in this case.
>
> Please tell me which option you like best or if it should be done
> differently. I've prepared a few RFCs (see links), but once we
> settled for the process, I'll make a proper announcement + patches.
>
> Regards
>
> Christian
>
> [1] <https://drive.google.com/folderview?id=0BwOU1CguSZuBdGYxVVlTWnpXSm8>
> [2] <https://drive.google.com/folderview?id=0BwOU1CguSZuBT1V2V0s2Smp0UmM>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] rtlwifi: fix null dereference on efuse_word on kmalloc fail returns NULL
From: Colin King @ 2013-10-28 12:58 UTC (permalink / raw)
To: Larry Finger, John W. Linville, linux-wireless
From: Colin Ian King <colin.king@canonical.com>
kmalloc on efuse_word can return null, leading to free'ing of
elements in efuse_word on the error exit path even though it has not
been allocated. Instead, don't free the elements of efuse_word if
kmalloc failed.
Also, kmalloc of any of the arrays in efuse_word[] can also fail,
leading to undefined contents in the remaining elements leading to
problems when free'ing these elements later on. So kzalloc efuse_word
to ensure the kfree on the remaining elements won't cause breakage.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/rtlwifi/efuse.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index 838a1ed..66f0b2d 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -262,9 +262,9 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16 _size_byte, u8 *pbuf)
sizeof(u8), GFP_ATOMIC);
if (!efuse_tbl)
return;
- efuse_word = kmalloc(EFUSE_MAX_WORD_UNIT * sizeof(u16 *), GFP_ATOMIC);
+ efuse_word = kzalloc(EFUSE_MAX_WORD_UNIT * sizeof(u16 *), GFP_ATOMIC);
if (!efuse_word)
- goto done;
+ goto out;
for (i = 0; i < EFUSE_MAX_WORD_UNIT; i++) {
efuse_word[i] = kmalloc(efuse_max_section * sizeof(u16),
GFP_ATOMIC);
@@ -378,6 +378,7 @@ done:
for (i = 0; i < EFUSE_MAX_WORD_UNIT; i++)
kfree(efuse_word[i]);
kfree(efuse_word);
+out:
kfree(efuse_tbl);
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Johannes Berg @ 2013-10-28 13:45 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, David S. Miller, linux-wireless,
netdev, linux-kernel, freemangordon, aaro.koskinen, pavel, sre,
joni.lapilainen
In-Reply-To: <1382819655-30430-17-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> Driver wl1251 generating mac address randomly at startup and there is no way to
> set permanent mac address via SET_IEEE80211_PERM_ADDR. This patch export sysfs
> file which can set permanent mac address by userspace helper program. Patch is
> needed for devices which do not store mac address in internal wl1251 eeprom.
This doesn't really seem like a good idea since you can also just use
'ip' or whatever to set the MAC address.
johannes
^ permalink raw reply
* Re: [PATCH 15/16] wl1251: Add sysfs file tx_mgmt_frm_rate for setting rate
From: Johannes Berg @ 2013-10-28 13:45 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, David S. Miller, linux-wireless,
netdev, linux-kernel, freemangordon, aaro.koskinen, pavel, sre,
joni.lapilainen
In-Reply-To: <1382819655-30430-16-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> This patch was extracted from Maemo 2.6.28 kernel
That's not a description or justification for the patch ....
but again, it seems like a bad idea to use sysfs.
johannes
^ permalink raw reply
* Re: [PATCH 01/16] mac80211: fix TX device statistics for monitor interfaces
From: Johannes Berg @ 2013-10-28 13:47 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, David S. Miller, linux-wireless,
netdev, linux-kernel, freemangordon, aaro.koskinen, pavel, sre,
joni.lapilainen, David Gnedt
In-Reply-To: <1382819655-30430-2-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> + dev->stats.tx_packets++;
> + dev->stats.tx_bytes += skb->len;
We can still easily drop the packet after this - we can't guarantee
it'll go out but maybe we shouldn't do it here?
johannes
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Pali Rohár @ 2013-10-28 13:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Luciano Coelho, John W. Linville, David S. Miller, linux-wireless,
netdev, linux-kernel, freemangordon, aaro.koskinen, pavel, sre,
joni.lapilainen
In-Reply-To: <1382967905.17956.8.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: Text/Plain, Size: 726 bytes --]
On Monday 28 October 2013 14:45:05 Johannes Berg wrote:
> On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> > Driver wl1251 generating mac address randomly at startup and
> > there is no way to set permanent mac address via
> > SET_IEEE80211_PERM_ADDR. This patch export sysfs file which
> > can set permanent mac address by userspace helper program.
> > Patch is needed for devices which do not store mac address
> > in internal wl1251 eeprom.
>
> This doesn't really seem like a good idea since you can also
> just use 'ip' or whatever to set the MAC address.
>
> johannes
AFAIK you cannot set permanent address (show by ethtool -P wlan0)
via ip/ifconfig.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Johannes Berg @ 2013-10-28 13:55 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, David S. Miller, linux-wireless,
netdev, linux-kernel, freemangordon, aaro.koskinen, pavel, sre,
joni.lapilainen
In-Reply-To: <201310281449.58170@pali>
On Mon, 2013-10-28 at 14:49 +0100, Pali Rohár wrote:
> On Monday 28 October 2013 14:45:05 Johannes Berg wrote:
> > On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> > > Driver wl1251 generating mac address randomly at startup and
> > > there is no way to set permanent mac address via
> > > SET_IEEE80211_PERM_ADDR. This patch export sysfs file which
> > > can set permanent mac address by userspace helper program.
> > > Patch is needed for devices which do not store mac address
> > > in internal wl1251 eeprom.
> >
> > This doesn't really seem like a good idea since you can also
> > just use 'ip' or whatever to set the MAC address.
> >
> > johannes
>
> AFAIK you cannot set permanent address (show by ethtool -P wlan0)
> via ip/ifconfig.
You probably can't, but that address also doesn't matter at all and
isn't really used anywhere.
johannes
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: a few genregdb.awk updates
From: Johannes Berg @ 2013-10-28 13:58 UTC (permalink / raw)
To: Luis R. Rodriguez, John Linville; +Cc: linux-wireless, wireless-regdb
In-Reply-To: <1382926786-7904-1-git-send-email-mcgrof@do-not-panic.com>
I'd apply this, but would prefer John to take a look - he wrote the awk
script and I'm not familiar with it.
johannes
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Pali Rohár @ 2013-10-28 14:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Luciano Coelho, John W. Linville, David S. Miller, linux-wireless,
netdev, linux-kernel, freemangordon, aaro.koskinen, pavel, sre,
joni.lapilainen
In-Reply-To: <1382968522.17956.11.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: Text/Plain, Size: 1415 bytes --]
On Monday 28 October 2013 14:55:22 Johannes Berg wrote:
> On Mon, 2013-10-28 at 14:49 +0100, Pali Rohár wrote:
> > On Monday 28 October 2013 14:45:05 Johannes Berg wrote:
> > > On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> > > > Driver wl1251 generating mac address randomly at startup
> > > > and there is no way to set permanent mac address via
> > > > SET_IEEE80211_PERM_ADDR. This patch export sysfs file
> > > > which can set permanent mac address by userspace helper
> > > > program. Patch is needed for devices which do not store
> > > > mac address in internal wl1251 eeprom.
> > >
> > > This doesn't really seem like a good idea since you can
> > > also just use 'ip' or whatever to set the MAC address.
> > >
> > > johannes
> >
> > AFAIK you cannot set permanent address (show by ethtool -P
> > wlan0) via ip/ifconfig.
>
> You probably can't, but that address also doesn't matter at
> all and isn't really used anywhere.
>
> johannes
There are some (proprietary) applications which using permanent
address for something...
And also more important: some network managing tools using it.
NetworkManager resetting current MAC address to permanent one
before starting configuring interface.
So this will lead to never use correct MAC address (but random
permanent one) assigned for that wl1251 wireless card...
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: iwlegacy (4965) - what would 0x8000 as the completed TX rate indicate?
From: Johannes Berg @ 2013-10-28 14:02 UTC (permalink / raw)
To: Adrian Chadd; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAJ-Vmok4rDn1Q5qCU2Oz=CVsqkJvYC0D+CmQL+WpwU+9qKHzrw@mail.gmail.com>
On Sat, 2013-10-26 at 16:56 -0700, Adrian Chadd wrote:
> Hi all,
>
> I'm debugging some issues that i see with the 4965 driver on FreeBSD. I
> figure maybe someone here with experience with the iwlegacy driver may know.
My 4965 knowledge is rusty ...
> I've set it up to do non-aggregate 11abg only traffic in my tests and I do
> occasionally see the TX rate control completion status show the rate is
> 0x8000. I don't know to interpret it. It typically happens with the retry
> count being non-zero, but there are also completed frames with non-zero
> retry and normal rate results. The returned status is OK.
> Oct 26 16:06:11 lucy kernel: iwn4965_tx_done: qid 0 idx 210 retries 0 nkill 0 rate 4003 duration 294 status 201
> Oct 26 16:06:11 lucy kernel: iwn4965_tx_done: qid 0 idx 211 retries 0 nkill 0 rate 4003 duration 182 status 201
> Oct 26 16:06:11 lucy kernel: iwn4965_tx_done: qid 0 idx 212 retries 1 nkill 0 rate 8000 duration 616 status 201
> Oct 26 16:06:12 lucy kernel: iwn4965_tx_done: qid 0 idx 213 retries 0 nkill 0 rate 4003 duration 294 status 201
> Oct 26 16:06:12 lucy kernel: iwn4965_tx_done: qid 0 idx 214 retries 1 nkill 0 rate 8000 duration 292 status 201
> Oct 26 16:06:12 lucy kernel: iwn4965_tx_done: qid 0 idx 215 retries 0 nkill 0 rate 4003 duration 86 status 201
> Oct 26 16:06:12 lucy kernel: iwn4965_tx_done: qid 0 idx 216 retries 0 nkill 0 rate 4003 duration 86 status 201
>
> I definitely am programming the initial rate control fine and the flags
> field doesn't have the linkq stuff set, so it should be transmitting only
> at that rate.
>
> The status indicates things are transmitting and completing fine.
>
> So, any ideas what that 0x8000 rate in the rate completion means?
I think that just means it used the other antenna and rate 0, since the
bits 0x1c000 contain the antenna bitmap that was used (up to three can
be used for each transmission)
johannes
^ permalink raw reply
* [PATCH] nl80211: fix channel switch parsing
From: Johannes Berg @ 2013-10-28 14:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Andrei Otcheretianski
From: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
The nl80211 attribute NL80211_ATTR_CSA_C_OFF_BEACON should be nested
inside NL80211_ATTR_CSA_IES, but commit ee4bc9e75811d2c0cb5f2a2fc5b5
("nl80211: enable IBSS support for channel switch announcements")
added a check in the outer message attributes.
Fix channel switch calls by removing the erroneus condition.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
[reword commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c49f0af..8ced6bc 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5713,9 +5713,7 @@ static int nl80211_channel_switch(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
/* only important for AP, IBSS and mesh create IEs internally */
- if (need_new_beacon &&
- (!info->attrs[NL80211_ATTR_CSA_IES] ||
- !info->attrs[NL80211_ATTR_CSA_C_OFF_BEACON]))
+ if (need_new_beacon && !info->attrs[NL80211_ATTR_CSA_IES])
return -EINVAL;
params.count = nla_get_u32(info->attrs[NL80211_ATTR_CH_SWITCH_COUNT]);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 1/4] nl80211: check nla_put_* return values
From: Johannes Berg @ 2013-10-28 14:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Coverity pointed out that in a few functions we don't
check the return value of the nla_put_*() calls. Most
of these are fairly harmless because the input isn't
very dynamic and controlled by the kernel, but the
pattern is simply wrong, so fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 52 +++++++++++++++++++++++++++++---------------------
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8ced6bc..1fef427 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -9633,8 +9633,9 @@ static int nl80211_add_scan_req(struct sk_buff *msg,
nla_put(msg, NL80211_ATTR_IE, req->ie_len, req->ie))
goto nla_put_failure;
- if (req->flags)
- nla_put_u32(msg, NL80211_ATTR_SCAN_FLAGS, req->flags);
+ if (req->flags &&
+ nla_put_u32(msg, NL80211_ATTR_SCAN_FLAGS, req->flags))
+ goto nla_put_failure;
return 0;
nla_put_failure:
@@ -11118,16 +11119,18 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
wakeup->pattern_idx))
goto free_msg;
- if (wakeup->tcp_match)
- nla_put_flag(msg, NL80211_WOWLAN_TRIG_WAKEUP_TCP_MATCH);
+ if (wakeup->tcp_match &&
+ nla_put_flag(msg, NL80211_WOWLAN_TRIG_WAKEUP_TCP_MATCH))
+ goto free_msg;
- if (wakeup->tcp_connlost)
- nla_put_flag(msg,
- NL80211_WOWLAN_TRIG_WAKEUP_TCP_CONNLOST);
+ if (wakeup->tcp_connlost &&
+ nla_put_flag(msg, NL80211_WOWLAN_TRIG_WAKEUP_TCP_CONNLOST))
+ goto free_msg;
- if (wakeup->tcp_nomoretokens)
- nla_put_flag(msg,
- NL80211_WOWLAN_TRIG_WAKEUP_TCP_NOMORETOKENS);
+ if (wakeup->tcp_nomoretokens &&
+ nla_put_flag(msg,
+ NL80211_WOWLAN_TRIG_WAKEUP_TCP_NOMORETOKENS))
+ goto free_msg;
if (wakeup->packet) {
u32 pkt_attr = NL80211_WOWLAN_TRIG_WAKEUP_PKT_80211;
@@ -11263,24 +11266,29 @@ void cfg80211_ft_event(struct net_device *netdev,
return;
hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_FT_EVENT);
- if (!hdr) {
- nlmsg_free(msg);
- return;
- }
+ if (!hdr)
+ goto out;
+
+ if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
+ nla_put_u32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex) ||
+ nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, ft_event->target_ap))
+ goto out;
- nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx);
- nla_put_u32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex);
- nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, ft_event->target_ap);
- if (ft_event->ies)
- nla_put(msg, NL80211_ATTR_IE, ft_event->ies_len, ft_event->ies);
- if (ft_event->ric_ies)
- nla_put(msg, NL80211_ATTR_IE_RIC, ft_event->ric_ies_len,
- ft_event->ric_ies);
+ if (ft_event->ies &&
+ nla_put(msg, NL80211_ATTR_IE, ft_event->ies_len, ft_event->ies))
+ goto out;
+ if (ft_event->ric_ies &&
+ nla_put(msg, NL80211_ATTR_IE_RIC, ft_event->ric_ies_len,
+ ft_event->ric_ies))
+ goto out;
genlmsg_end(msg, hdr);
genlmsg_multicast_netns(wiphy_net(&rdev->wiphy), msg, 0,
nl80211_mlme_mcgrp.id, GFP_KERNEL);
+ return;
+ out:
+ nlmsg_free(msg);
}
EXPORT_SYMBOL(cfg80211_ft_event);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 2/4] nl80211: fix error path in nl80211_get_key()
From: Johannes Berg @ 2013-10-28 14:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1382969304-25611-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Coverity pointed out that in the (practically impossible)
error case we leak the message - fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1fef427..22df144 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2668,7 +2668,7 @@ static int nl80211_get_key(struct sk_buff *skb, struct genl_info *info)
hdr = nl80211hdr_put(msg, info->snd_portid, info->snd_seq, 0,
NL80211_CMD_NEW_KEY);
if (!hdr)
- return -ENOBUFS;
+ goto nla_put_failure;
cookie.msg = msg;
cookie.idx = key_idx;
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 4/4] mac80211: remove useless tests for array
From: Johannes Berg @ 2013-10-28 14:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1382969304-25611-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Coverity points out that checking assoc_data->ie is
completely useless since it's an array in the struct
and can't be NULL - remove the useless checks.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 1305ff9..5b2b0a1 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -714,7 +714,7 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata)
}
/* if present, add any custom IEs that go before HT */
- if (assoc_data->ie_len && assoc_data->ie) {
+ if (assoc_data->ie_len) {
static const u8 before_ht[] = {
WLAN_EID_SSID,
WLAN_EID_SUPP_RATES,
@@ -748,7 +748,7 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata)
&assoc_data->ap_vht_cap);
/* if present, add any custom non-vendor IEs that go after HT */
- if (assoc_data->ie_len && assoc_data->ie) {
+ if (assoc_data->ie_len) {
noffset = ieee80211_ie_split_vendor(assoc_data->ie,
assoc_data->ie_len,
offset);
@@ -779,7 +779,7 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata)
}
/* add any remaining custom (i.e. vendor specific here) IEs */
- if (assoc_data->ie_len && assoc_data->ie) {
+ if (assoc_data->ie_len) {
noffset = assoc_data->ie_len;
pos = skb_put(skb, noffset - offset);
memcpy(pos, assoc_data->ie + offset, noffset - offset);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 3/4] nl80211: check nla_nest_start() return value
From: Johannes Berg @ 2013-10-28 14:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1382969304-25611-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Coverity pointed out that we might dereference NULL later
if nla_nest_start() returns a failure. This isn't really
true since we'd bomb out before, but we should check the
return value directly, so do that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 22df144..99dc3f3 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11094,6 +11094,8 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
struct nlattr *reasons;
reasons = nla_nest_start(msg, NL80211_ATTR_WOWLAN_TRIGGERS);
+ if (!reasons)
+ goto free_msg;
if (wakeup->disconnect &&
nla_put_flag(msg, NL80211_WOWLAN_TRIG_DISCONNECT))
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH] cfg80211: add missing break in cfg80211_get_chan_state()
From: Johannes Berg @ 2013-10-28 14:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Improve readability of the function by adding the break,
there's no functional impact but it's confusing to fall
through.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/chan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 9b8cc87..59c4f9a 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -510,6 +510,7 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
: CHAN_MODE_EXCLUSIVE;
return;
}
+ break;
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_P2P_CLIENT:
if (wdev->current_bss) {
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH] cfg80211: don't allow drivers to unset NL80211_FEATURE_SCAN_FLUSH
From: Johannes Berg @ 2013-10-28 14:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
As the flag is entirely implemented in cfg80211, it should
have been a global feature flag (which I believe didn't
exist at the time). However, there's no reason to allow
drivers to unset the flag, so don't allow it and remove
the validation of NL80211_SCAN_FLAG_FLUSH.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/core.c | 3 +--
net/wireless/nl80211.c | 12 ++++--------
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6715396..93d367c 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -357,8 +357,6 @@ struct wiphy *wiphy_new(const struct cfg80211_ops *ops, int sizeof_priv)
rdev->wiphy.rts_threshold = (u32) -1;
rdev->wiphy.coverage_class = 0;
- rdev->wiphy.features = NL80211_FEATURE_SCAN_FLUSH;
-
return &rdev->wiphy;
}
EXPORT_SYMBOL(wiphy_new);
@@ -566,6 +564,7 @@ int wiphy_register(struct wiphy *wiphy)
/* check and set up bitrates */
ieee80211_set_bitrate_flags(wiphy);
+ rdev->wiphy.features |= NL80211_FEATURE_SCAN_FLUSH;
res = device_add(&rdev->wiphy.dev);
if (res)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 99dc3f3..2c4ac01 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5342,10 +5342,8 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_SCAN_FLAGS]) {
request->flags = nla_get_u32(
info->attrs[NL80211_ATTR_SCAN_FLAGS]);
- if (((request->flags & NL80211_SCAN_FLAG_LOW_PRIORITY) &&
- !(wiphy->features & NL80211_FEATURE_LOW_PRIORITY_SCAN)) ||
- ((request->flags & NL80211_SCAN_FLAG_FLUSH) &&
- !(wiphy->features & NL80211_FEATURE_SCAN_FLUSH))) {
+ if ((request->flags & NL80211_SCAN_FLAG_LOW_PRIORITY) &&
+ !(wiphy->features & NL80211_FEATURE_LOW_PRIORITY_SCAN)) {
err = -EOPNOTSUPP;
goto out_free;
}
@@ -5585,10 +5583,8 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
if (info->attrs[NL80211_ATTR_SCAN_FLAGS]) {
request->flags = nla_get_u32(
info->attrs[NL80211_ATTR_SCAN_FLAGS]);
- if (((request->flags & NL80211_SCAN_FLAG_LOW_PRIORITY) &&
- !(wiphy->features & NL80211_FEATURE_LOW_PRIORITY_SCAN)) ||
- ((request->flags & NL80211_SCAN_FLAG_FLUSH) &&
- !(wiphy->features & NL80211_FEATURE_SCAN_FLUSH))) {
+ if ((request->flags & NL80211_SCAN_FLAG_LOW_PRIORITY) &&
+ !(wiphy->features & NL80211_FEATURE_LOW_PRIORITY_SCAN)) {
err = -EOPNOTSUPP;
goto out_free;
}
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH] mac80211_hwsim: Fix tracking of beaconing for multi-vif
From: Johannes Berg @ 2013-10-28 14:12 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John W. Linville, linux-wireless
In-Reply-To: <20131022111117.GA9983@jouni.qca.qualcomm.com>
On Tue, 2013-10-22 at 14:11 +0300, Jouni Malinen wrote:
> mac80211_hwsim canceled beacon_timer on any vif changing from enabled
> to disabled beaconing. This breaks cases where there are multiple
> beaconing vifs and only one of them is removed. Fix this by tracking
> beaconing status per vif and disable beacon_timer only if no active vif
> remain with beaconing enabled.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: fix channel switch parsing
From: Johannes Berg @ 2013-10-28 14:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Andrei Otcheretianski
In-Reply-To: <1382969267-25506-1-git-send-email-johannes@sipsolutions.net>
On Mon, 2013-10-28 at 15:07 +0100, Johannes Berg wrote:
> From: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
>
> The nl80211 attribute NL80211_ATTR_CSA_C_OFF_BEACON should be nested
> inside NL80211_ATTR_CSA_IES, but commit ee4bc9e75811d2c0cb5f2a2fc5b5
> ("nl80211: enable IBSS support for channel switch announcements")
> added a check in the outer message attributes.
>
> Fix channel switch calls by removing the erroneus condition.
Applied (Simon had already looked at it before)
johannes
^ permalink raw reply
* Re: [PATCH 3.12] cfg80211: fix ibss wext chandef creation
From: Johannes Berg @ 2013-10-28 14:21 UTC (permalink / raw)
To: Simon Wunderlich
Cc: linux-wireless, Mathias Kretschmer, Dirk Gouders, Linux Kernel
In-Reply-To: <1382472166-19563-1-git-send-email-sw@simonwunderlich.de>
On Tue, 2013-10-22 at 22:02 +0200, Simon Wunderlich wrote:
> The wext internal chandefs for ibss should be created using the
> cfg80211_chandef_create() functions. Otherwise the center_freq1 field
> will not be set and cfg80211_chandef_valid() will spit a warning and
> report the chandef as invalid when it should be used.
I think
commit f478f33a93f9353dcd1fe55445343d76b1c3f84a
Author: Bruno Randolf <br1@einfach.org>
Date: Thu Sep 26 16:55:28 2013 +0100
cfg80211: fix warning when using WEXT for IBSS
already fixed this. Your patch doesn't apply, but feel free to send me a
new one (for -next) converting to the creation helpers.
johannes
^ permalink raw reply
* Re: BRCM 4324 Help
From: Arend van Spriel @ 2013-10-28 14:22 UTC (permalink / raw)
To: Hiemanshu Sharma, linux-wireless
In-Reply-To: <CA+fH8T-QQKzhH4yHv1wqg5f0PXqYAg3amXctQOCG8zwqrDEM1w@mail.gmail.com>
On 10/26/2013 10:54 PM, Hiemanshu Sharma wrote:
> Hey,
>
> Trying to follow the instructions at
> http://wireless.kernel.org/en/users/Drivers/brcm80211 I need a
> brcmfmac-sdio.txt with the nvram values but I am not able to find out
> where to get the file from. I've tried google a lot but there doesn't
> seem to be a lot of help out there.
>
> dmesg says :
>
> brcmfam: brcmf_sdbrcm_download_nvram : Fail to request nvram -2
> brcmfmac: _brcmf_sdbrcm_download_firmware: dongle nvram file download failed
A good day to you.
What platform are you attempting to use here?
Regards,
Arend
> I've used firmware from the git, and the message for missing firmware
> is not shown anymore.
>
> Regards,
>
> Hiemanshu Sharma.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] nl80211: introduce NL80211_SCAN_FLAG_DISCOVERY_MODE
From: Johannes Berg @ 2013-10-28 14:37 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: linux-wireless, Luis R . Rodriguez, John W . Linville,
Jouni Malinen
In-Reply-To: <1382889282-12880-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
On Sun, 2013-10-27 at 17:54 +0200, Vladimir Kondratiev wrote:
> for the DMG (60GHz) networks, there is new scan parameter added in the 802.11 spec -
> DiscoveryMode. This parameter defines whether station performing active scan shall
> generate special form of DMG beacons. In particular, this flag used in the P2P
> discovery.
Max 72 chars per line please.
> + * @NL80211_SCAN_FLAG_DISCOVERY_MODE: scan to use discovery mode, as in
"scan to use" - did you mean "scan using"?
Also what about a feature flag? Though I suppose this should be
supported by all 60GHz devices (and only those)?
johannes
^ permalink raw reply
* Re: [PATCH 01/14] cfg80211: consolidate passive-scan and no-ibss flags
From: Johannes Berg @ 2013-10-28 14:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville, linux-wireless, janusz.dziedzic, smihir, tushnimb
In-Reply-To: <1382376158-25586-2-git-send-email-mcgrof@do-not-panic.com>
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -2206,10 +2206,9 @@ enum nl80211_band_attr {
> * @NL80211_FREQUENCY_ATTR_FREQ: Frequency in MHz
> * @NL80211_FREQUENCY_ATTR_DISABLED: Channel is disabled in current
> * regulatory domain.
> - * @NL80211_FREQUENCY_ATTR_PASSIVE_SCAN: Only passive scanning is
> - * permitted on this channel in current regulatory domain.
> - * @NL80211_FREQUENCY_ATTR_NO_IBSS: IBSS networks are not permitted
> - * on this channel in current regulatory domain.
> + * @NL80211_FREQUENCY_ATTR_NO_IR: no mechanisms that initiate radiation
> + * are permitted on this channel, this includes sending probe
> + * requests, or modes of operation that require beaconing.
> * @NL80211_FREQUENCY_ATTR_RADAR: Radar detection is mandatory
> * on this channel in current regulatory domain.
> * @NL80211_FREQUENCY_ATTR_MAX_TX_POWER: Maximum transmission power in mBm
> @@ -2236,8 +2235,8 @@ enum nl80211_frequency_attr {
> __NL80211_FREQUENCY_ATTR_INVALID,
> NL80211_FREQUENCY_ATTR_FREQ,
> NL80211_FREQUENCY_ATTR_DISABLED,
> - NL80211_FREQUENCY_ATTR_PASSIVE_SCAN,
> - NL80211_FREQUENCY_ATTR_NO_IBSS,
> + NL80211_FREQUENCY_ATTR_NO_IR,
> + __NL80211_FREQUENCY_ATTR_NO_IBSS,
> NL80211_FREQUENCY_ATTR_RADAR,
> NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
> NL80211_FREQUENCY_ATTR_DFS_STATE,
I don't think you can make this change, it breaks API and ABI because
the old IBSS flag is now ignored on input from old CRDA?
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: clarify DFS / CAC case for the new NO-IR flag
From: Johannes Berg @ 2013-10-28 14:43 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville, linux-wireless, janusz.dziedzic, smihir, tushnimb
In-Reply-To: <1382376440-25838-1-git-send-email-mcgrof@do-not-panic.com>
On Mon, 2013-10-21 at 19:27 +0200, Luis R. Rodriguez wrote:
> Now that the no-ibss and passive-scan flags are bundled
> together its a lot easier to deal with the case of when
> we support DFS. If DFS is supported on the wiphy and if
> the Channel availability check (CAC) has been cleared on
> the channel (dfs_state is NL80211_DFS_AVAILABLE) we can
> ignore the no-ir flag.
>
> This simplifies the paranoid requirement of bundling
> together DFS and NO-IR cases by placing onus on the
> DFS implementation. If code paths also want to reuse
> knowledge from DFS state machines they must also ensure
> that they always look at and monitor the dfs_state.
Please resend this as part of the other series when my comment there is
sorted out. (Unless nothing is needed, in which case just remind me to
pick this up if I forget)
johannes
^ permalink raw reply
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