* [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
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Johannes Berg @ 2013-10-28 14:44 UTC (permalink / raw)
To: Chauhan, Rajesh
Cc: linux-wireless@vger.kernel.org, Rodriguez, Luis, Malinen, Jouni,
Bahini, Henri, Chang, Leo, Luo, Xun
In-Reply-To: <D19FD2B13A40CD4B8DA64DB9B8F112E9218DAC92@nasanexd01a.na.qualcomm.com>
On Thu, 2013-10-17 at 17:19 +0000, Chauhan, Rajesh wrote:
> Hi Johannes,
>
> Thanks for your comment. Purpose of this patch is to add an API for
> WLAN driver to report frequency ranges which should be avoided for
> SAP/P2P-GO because of interference.
>
> How about if I reword commit test as below?
>
> cfg80211/nl80211: Add API to report frequency range(s) to be avoided
>
> Add support for WLAN driver to report frequency range(s) to be avoided
> because of interference.
Wouldn't it make more sense to raise a "detected interference" event?
There's no way to know what channel range is affected anyway. I fear
that this is vague enough for you to (ab)use it for all kinds of random
"channel steering" from the driver.
johannes
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Dan Williams @ 2013-10-28 14:46 UTC (permalink / raw)
To: Pali Rohár
Cc: Johannes Berg, Luciano Coelho, John W. Linville, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <201310281500.24159@pali>
On Mon, 2013-10-28 at 15:00 +0100, Pali Rohár wrote:
> 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...
If the device doesn't actually *have* a permanent MAC address, then it
shouldn't be returning one via ethtool, and should return an error for
ETHTOOL_GPERMADDR. Setting the permanent MAC address shouldn't ever be
allowed except by the driver inspecting EEPROM, and certainly not via
sysfs.
mac80211 does have to do some special stuff due to virtual interfaces
and such, but in general, if the MAC address is randomly generated,
neither the driver nor mac80211 should be reporting that address as the
permanent address, only as the current one.
Dan
^ permalink raw reply
* Re: [PATCH 01/14] cfg80211: consolidate passive-scan and no-ibss flags
From: Luis R. Rodriguez @ 2013-10-28 14:49 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, linux-wireless, Janusz Dziedzic, smihir,
tushnimb
In-Reply-To: <1382971344.17956.27.camel@jlt4.sipsolutions.net>
On Mon, Oct 28, 2013 at 3:42 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> 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?
I addressed that by mapping it to NO-IR in-kernel, if it was used. In
other words if userspace sends it we'll respect it in the same way.
Luis
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Johannes Berg @ 2013-10-28 14:56 UTC (permalink / raw)
To: Dan Williams
Cc: Pali Rohár, Luciano Coelho, John W. Linville,
David S. Miller, linux-wireless, netdev, linux-kernel,
freemangordon, aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <1382971562.1542.6.camel@dcbw.foobar.com>
On Mon, 2013-10-28 at 09:46 -0500, Dan Williams wrote:
> If the device doesn't actually *have* a permanent MAC address, then it
> shouldn't be returning one via ethtool, and should return an error for
> ETHTOOL_GPERMADDR.
There's currently no provision for that, but I agree it would be better
to do so.
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: introduce NL80211_SCAN_FLAG_DISCOVERY_MODE
From: Johannes Berg @ 2013-10-28 15:00 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: linux-wireless, Luis R . Rodriguez, John W . Linville,
Jouni Malinen
In-Reply-To: <1382971021.17956.25.camel@jlt4.sipsolutions.net>
Ok, so you can't even get your own email address right - I'll ignore you
for a few weeks until you maybe get it right.
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 15:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Dan Williams, Luciano Coelho, John W. Linville, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <1382972215.17956.30.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: Text/Plain, Size: 819 bytes --]
On Monday 28 October 2013 15:56:55 Johannes Berg wrote:
> On Mon, 2013-10-28 at 09:46 -0500, Dan Williams wrote:
> > If the device doesn't actually *have* a permanent MAC
> > address, then it shouldn't be returning one via ethtool,
> > and should return an error for ETHTOOL_GPERMADDR.
>
> There's currently no provision for that, but I agree it would
> be better to do so.
>
> johannes
So what to do with devices which has MAC address stored in some
obscure place and there is userspace binary which can read it?
I think that there should be some way to tell kernel that *this*
is the permanent address and it should use it.
This is reason why I proposed patch which adding sysfs entry for
setting permanent address from userspace in wl1251 driver.
--
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: Dan Williams @ 2013-10-28 15:29 UTC (permalink / raw)
To: Pali Rohár
Cc: Johannes Berg, Luciano Coelho, John W. Linville, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <201310281604.48542@pali>
On Mon, 2013-10-28 at 16:04 +0100, Pali Rohár wrote:
> On Monday 28 October 2013 15:56:55 Johannes Berg wrote:
> > On Mon, 2013-10-28 at 09:46 -0500, Dan Williams wrote:
> > > If the device doesn't actually *have* a permanent MAC
> > > address, then it shouldn't be returning one via ethtool,
> > > and should return an error for ETHTOOL_GPERMADDR.
> >
> > There's currently no provision for that, but I agree it would
> > be better to do so.
> >
> > johannes
>
> So what to do with devices which has MAC address stored in some
> obscure place and there is userspace binary which can read it?
>
> I think that there should be some way to tell kernel that *this*
> is the permanent address and it should use it.
>
> This is reason why I proposed patch which adding sysfs entry for
> setting permanent address from userspace in wl1251 driver.
Ok, so the N900's MAC is stored in the "cal partition", which is a
region of flash exposed to the OS as /dev/mtd1. That also stores the
regulatory domain. Typically userspace binaries are used to pull out
this and other data (see
https://dev.openwrt.org/browser/packages/utils/calvaria/files/src/calvaria.c ) which is then used to initialize the device.
Any idea what kernel driver is used to expose the CAL partition
as /dev/mtd1? If it's nothing special maybe a small EEPROM-style driver
could be written to read the relevant areas (and since they don't ever
change, don't need to worry about something else writing at the same
time).
Dan
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Stephen Hemminger @ 2013-10-28 15:33 UTC (permalink / raw)
To: Johannes Berg
Cc: Dan Williams, Pali Rohár, Luciano Coelho, John W. Linville,
David S. Miller, linux-wireless, netdev, linux-kernel,
freemangordon, aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <1382972215.17956.30.camel@jlt4.sipsolutions.net>
On Mon, 28 Oct 2013 15:56:55 +0100
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2013-10-28 at 09:46 -0500, Dan Williams wrote:
>
> > If the device doesn't actually *have* a permanent MAC address, then it
> > shouldn't be returning one via ethtool, and should return an error for
> > ETHTOOL_GPERMADDR.
>
> There's currently no provision for that, but I agree it would be better
> to do so.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
The current netdevice API handle the case of a device without a permanent
MAC address, slightly differently.
If device does not have a permanent address,
then:
1. dev->addr_assign_type should not be NET_ADDR_PERM
2. when device is registered dev->perm_addr will not be set
and retain all zeros value
4. when ethtool gets address it will return all zeros which
is not a valid address.
This case doesn't seem to be handled threo mac80211 API's
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 15:44 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless Mailing List, ilw, hostap@lists.shmoo.com
In-Reply-To: <526E33C3.60302@rempel-privat.de>
On Mon, Oct 28, 2013 at 3:52 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 28.10.2013 10:38, schrieb Felipe Contreras:
>> On Mon, Oct 28, 2013 at 2:31 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>> Heh... this logs look like miracle :)
>>> My first assumption would be buggy router. There is no answer in
>>> wpa_supplicant log.
>>
>> Yeah, I bet the router is buggy, which router isn't? But why Windows 7
>> connects fine?
>
> May be it includes some workaround?
> You do not need to fight with devs, i think they are agree that some
> thing is wrong. But believe me, there are so many access points, which
> make problems or wear things. If you have a bug, does not mean other
> user have it.
I understand the problems of making wireless drivers work on different
kinds of access points, and I'm not fighting with devs, I'm just
saying that if it works in all other devices the problem is most
likely on this one.
And BTW, the devices we are talking about are very varied: Wii U,
Windows 7, Windows 8.1, Nokia N9, Android phone, iPhone, iMac, Amazon
Kindle. Yet the only device that seems to have a problem is my Linux
machine, I think it's pretty clear where the problem is.
And sure, it does not necessarily means that other people have the
same problem, but it is very unlikely that I'm the only one.
> Beside, how many clients use this AP?
Probably around a dozen.
> How big is the distance?
Probably around 10m.
> What do you configure in AdHock mode?
Nothing, I don't think it even works, but it associates. I just add mode=1.
network={
ssid="AXTEL-XXX"
proto=WPA2
scan_ssid=1
key_mgmt=WPA-PSK
psk="XXX"
mode=1
}
>>> Take wireshark and capture working and not working associational request.
>>
>> I'll try that. If only it was that easy to get a working association.
>
> Compare it with windows.
Right, I forgot I can use wireshark in Windows.
> and please read this, it will help to provide more information.
> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
I don't understand what exactly do you need from that list. I'm using
3.11.6, but as I said in the original report, the kernel version makes
no difference, even as far back as 3.6.0. I've put the dmesg log in
the original mail and there's nothing of value there. I could try
running with CONFIG_MAC80211_*_DEBUG stuff enabled, but do you really
think that will help?
If you really must know, this is exactly what I'm running:
config=$(mktemp)
pid="/run/wpa_supplicant_wlan0.pid"
cat > $config <<-EOF
country=MX
ap_scan=1
eapol_version=2
device_name=Nysa
device_type=1-0050F204-1
network={
ssid="AXTEL-7111"
proto=WPA2
scan_ssid=1
key_mgmt=WPA-PSK
psk="C3657111"
mode=0
}
EOF
wpa_supplicant -B -t -d -P $pid -i wlan0 -D nl80211,wext -c $config -f
/tmp/wpa.log
rm -f "$config"
I tried with wext, but that doesn't work at all. A curious fact is
that I need to enable CONFIG_CFG80211_WEXT=y for AP scanning to work,
even though I'm not using the wext driver.
I will try to get the wireshark logs.
--
Felipe Contreras
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 15:54 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, linux-wireless Mailing List, ilw,
hostap@lists.shmoo.com
In-Reply-To: <CABPxzYLUG-X=p5z4fJusH63EvtuOy=EKfeQPScHDwGDpAJoFYg@mail.gmail.com>
On Mon, Oct 28, 2013 at 5:00 AM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 3:07 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> 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.
Yeah, but if max-clients = 5, and clients = 5, nothing would change
when I reboot to Windows and it works. Also, if it's working on Linux,
I reboot my machine, and then I cannot connect again. Plus, I
disconnect my phone, I try to connect in Linux, it keeps failing, I
connect my phone, and my phone works.
I don't think this theory matches the evidence at all.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Pali Rohár @ 2013-10-28 16:21 UTC (permalink / raw)
To: Dan Williams
Cc: Johannes Berg, Luciano Coelho, John W. Linville, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <1382974161.1542.18.camel@dcbw.foobar.com>
[-- Attachment #1: Type: Text/Plain, Size: 1983 bytes --]
On Monday 28 October 2013 16:29:21 Dan Williams wrote:
> On Mon, 2013-10-28 at 16:04 +0100, Pali Rohár wrote:
> > On Monday 28 October 2013 15:56:55 Johannes Berg wrote:
> > > On Mon, 2013-10-28 at 09:46 -0500, Dan Williams wrote:
> > > > If the device doesn't actually *have* a permanent MAC
> > > > address, then it shouldn't be returning one via ethtool,
> > > > and should return an error for ETHTOOL_GPERMADDR.
> > >
> > > There's currently no provision for that, but I agree it
> > > would be better to do so.
> > >
> > > johannes
> >
> > So what to do with devices which has MAC address stored in
> > some obscure place and there is userspace binary which can
> > read it?
> >
> > I think that there should be some way to tell kernel that
> > *this* is the permanent address and it should use it.
> >
> > This is reason why I proposed patch which adding sysfs entry
> > for setting permanent address from userspace in wl1251
> > driver.
>
> Ok, so the N900's MAC is stored in the "cal partition", which
> is a region of flash exposed to the OS as /dev/mtd1. That
> also stores the regulatory domain. Typically userspace
> binaries are used to pull out this and other data (see
> https://dev.openwrt.org/browser/packages/utils/calvaria/files/
> src/calvaria.c ) which is then used to initialize the device.
>
> Any idea what kernel driver is used to expose the CAL
> partition as /dev/mtd1? If it's nothing special maybe a
> small EEPROM-style driver could be written to read the
> relevant areas (and since they don't ever change, don't need
> to worry about something else writing at the same time).
>
> Dan
/dev/mtd1 is second (0 is first) OneNand partition. Nothing
special. Kernel driver for OnaNand is already in mainline kernel.
That partition also has NVS device data for wl1251 chip.
And you are right calvaria has GPL v2 code for parsing data in
that partition.
--
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: I always need a miracle to connect with iwlwifi
From: Oleksij Rempel @ 2013-10-28 16:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: linux-wireless Mailing List, ilw, hostap@lists.shmoo.com
In-Reply-To: <CAMP44s05-NRskvWHNqzVxTRiB_2DeRsPwQGAZZ3saM-VC=ZyQA@mail.gmail.com>
Am 28.10.2013 16:44, schrieb Felipe Contreras:
> On Mon, Oct 28, 2013 at 3:52 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 28.10.2013 10:38, schrieb Felipe Contreras:
>>> On Mon, Oct 28, 2013 at 2:31 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>
>>>> Heh... this logs look like miracle :)
>>>> My first assumption would be buggy router. There is no answer in
>>>> wpa_supplicant log.
>>>
>>> Yeah, I bet the router is buggy, which router isn't? But why Windows 7
>>> connects fine?
>>
>> May be it includes some workaround?
>
>> You do not need to fight with devs, i think they are agree that some
>> thing is wrong. But believe me, there are so many access points, which
>> make problems or wear things. If you have a bug, does not mean other
>> user have it.
>
> I understand the problems of making wireless drivers work on different
> kinds of access points, and I'm not fighting with devs, I'm just
> saying that if it works in all other devices the problem is most
> likely on this one.
>
> And BTW, the devices we are talking about are very varied: Wii U,
> Windows 7, Windows 8.1, Nokia N9, Android phone, iPhone, iMac, Amazon
> Kindle. Yet the only device that seems to have a problem is my Linux
> machine, I think it's pretty clear where the problem is.
Do any of listed devices use mac80211? If not, you still have fallowing
options: wpa_supplicant, mac80211, iwlwifi driver, iwlwifi firmware. In
you arguments you even didn't tried to eliminate any of them. So, no. It
is not clear where problem is.
> And sure, it does not necessarily means that other people have the
> same problem, but it is very unlikely that I'm the only one.
what is your hardware? Did you tired to disable power save mode?
I have "Intel Centrino Advanced-N 6235", it use same driver and works
with three of my APs. I say just to show, that list of working hardware
is not helpful.
what is you AP? Mode it is running? Do changing settings of this AP
makes some difference? -- No, changing settings of you AP is not the way
to get you off.
>> Beside, how many clients use this AP?
>
> Probably around a dozen.
>
>> How big is the distance?
>
> Probably around 10m.
>
>> What do you configure in AdHock mode?
>
> Nothing, I don't think it even works, but it associates. I just add mode=1.
>
> network={
> ssid="AXTEL-XXX"
> proto=WPA2
> scan_ssid=1
> key_mgmt=WPA-PSK
> psk="XXX"
> mode=1
> }
>
>>>> Take wireshark and capture working and not working associational request.
>>>
>>> I'll try that. If only it was that easy to get a working association.
>>
>> Compare it with windows.
>
> Right, I forgot I can use wireshark in Windows.
>
>> and please read this, it will help to provide more information.
>> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
>
> I don't understand what exactly do you need from that list. I'm using
> 3.11.6, but as I said in the original report, the kernel version makes
> no difference, even as far back as 3.6.0. I've put the dmesg log in
> the original mail and there's nothing of value there. I could try
> running with CONFIG_MAC80211_*_DEBUG stuff enabled, but do you really
> think that will help?
>
> If you really must know, this is exactly what I'm running:
>
> config=$(mktemp)
> pid="/run/wpa_supplicant_wlan0.pid"
>
> cat > $config <<-EOF
> country=MX
> ap_scan=1
> eapol_version=2
> device_name=Nysa
> device_type=1-0050F204-1
>
> network={
> ssid="AXTEL-7111"
> proto=WPA2
> scan_ssid=1
> key_mgmt=WPA-PSK
> psk="C3657111"
> mode=0
> }
> EOF
>
> wpa_supplicant -B -t -d -P $pid -i wlan0 -D nl80211,wext -c $config -f
> /tmp/wpa.log
>
> rm -f "$config"
>
> I tried with wext, but that doesn't work at all. A curious fact is
> that I need to enable CONFIG_CFG80211_WEXT=y for AP scanning to work,
> even though I'm not using the wext driver.
>
> I will try to get the wireshark logs.
>
--
Regards,
Oleksij
^ 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