* Re: [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Andy Isaacson @ 2013-07-31 15:09 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Arkadiusz Miskiewicz, Stanislaw Gruszka,
Johannes Berg
In-Reply-To: <1375264234-31077-1-git-send-email-johannes@sipsolutions.net>
On Wed, Jul 31, 2013 at 11:50:34AM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> While we're connected, the AP shouldn't change the primary channel
> in the HT information. We checked this, and dropped the connection
> if it did change it.
>
> Unfortunately, this is causing problems on some APs, e.g. on the
> Netgear WRT610NL: the beacons seem to always contain a bad channel
> and if we made a connection using a probe response (correct data)
> we drop the connection immediately and can basically not connect
> properly at all.
>
> Work around this by ignoring the HT primary channel information in
> beacons if we're already connected.
>
> Also print out more verbose messages in the other situations to
> help diagnose similar bugs quicker in the future.
>
> Cc: stable@vger.kernel.org [3.10]
Acked-by: Andy Isaacson <adi@hexapodia.org>
LGTM. Wasn't able to test though. Recommend this for -stable,
regressing wifi connectivity makes it hard to report bugs.
-andy
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 15:11 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F9276F.1040908@broadcom.com>
This is my hook: it gets called after I set dev to wlan0. I used a
guide for this and it seems to work for my notebook where I'm able to
find the 802.3 header but still no 802.11.
static int ptype_function(struct sk_buff *skb, struct net_device *dev,
struct packet_type *ptype, struct net_device *dev2);
static void throw_hook(struct net_device *dev){
ptype.type = htons(ETH_P_ALL);
ptype.func = &ptype_function;
ptype.dev = dev;
dev_add_pack(&ptype);
printk(KERN_CRIT "Done setting up packet type");
}
All code can be found here:
android: https://github.com/mathieudevos/kernelmodules/blob/master/ethernet_test.c
notebook: https://github.com/mathieudevos/wifi_kernelmodules/blob/master/ethernet_test.c
Kind regards,
Mathieu Devos
On Wed, Jul 31, 2013 at 5:04 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 07/31/2013 03:45 PM, Mathieu Devos wrote:
>>
>> Alright,
>>
>> Seems like I have fixed some issues while added some others. Since I
>> assume that when my hook gets activated the data pointer should be at
>> the start of the 802.3 header I casted an ethhdr (8023) on top of that
>> and it seems that on my notebook this is handled correctly (I can
>> actually check on my own mac addr and see that these frames are
>> for/from me).
>
>
> How does your hook work? Are you intercepting packets?
>
> Regards,
> Arend
>
>
>> On Wed, Jul 31, 2013 at 2:55 PM, Arend van Spriel <arend@broadcom.com>
>> wrote:
>>>
>>> On 07/31/2013 02:39 PM, Mathieu Devos wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> The wireless chip is a Broadcast BCM4330 chip. After looking around a
>>>> bit I found that this is a fullMAC and links to the driver on
>>>> wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
>>>> and also links directly to android itself:
>>>> https://android.googlesource.com/platform/hardware/broadcom/wlan
>>>
>>>
>>>
>>> I suspected. The bcm4330 is indeed a fullmac device, which means the
>>> 802.11
>>> stack is running on the device. The driver on Android is located under:
>>>
>>>
>>> https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-ics-mr1/drivers/net/wireless/bcmdhd/
>>>
>>> Not sure which android version you have.
>>>
>>> The brcm80211 on wireless.kernel.org is the upstream linux driver.
>>>
>>> Gr. AvS
>>>
>>>
>>>> Still trying to learn a lot in this tightly packed world of protocol
>>>> stacks, wireless and all the other poisons. Seems like I still have a
>>>> long way to go. Thank you already for helping me out with these issues
>>>> and taking the time to explain these things to me.
>>>>
>>>> Kind regards,
>>>> Mathieu Devos
>>>>
>>>> On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>>>>>> have a normal ethernet 802.3 input even. I check before selecting the
>>>>>> device that it's wireless (through ieee80211_ptr) and this properly
>>>>>> returns the wlan0 device which should be on the 80211 standard.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *sigh* Welcome in the world of protocol stacks, wireless, networking
>>>>> (choose
>>>>> your poison). Let me draw the picture.
>>>>>
>>>>> o user-space
>>>>> |
>>>>> ----------------------
>>>>> | kernel
>>>>> +-----------+
>>>>> | NET | networking subsystem, ie. TCP/IP stack
>>>>> +-----------+
>>>>> | 802.3
>>>>> +----------------+
>>>>> | | driver |
>>>>> | +------------+ |
>>>>> | |802.11 stack| |
>>>>> | +------------+ |
>>>>> | | 802.11 |
>>>>> +----------------+
>>>>> |
>>>>> o RF
>>>>>
>>>>> The device hooks up to the networking subsystem as an ethernet device
>>>>> and
>>>>> as
>>>>> such it receives 802.3 packets. These are converted to 802.11 packets
>>>>> by
>>>>> the
>>>>> 802.11 stack. Now depending on your device that happens in the device
>>>>> driver
>>>>> or on the device itself. Another option is that this is done by
>>>>> mac80211
>>>>> (kernel provided 802.11 stack), but that is probably not the case, but
>>>>> to
>>>>> be
>>>>> sure I ask again: what wireless device do you have in your galaxy S2?
>>>>>
>>>>> Gr. AvS
>>>>>
>>>>>
>>>>>> My goal is to get the ieee80211_header properly on the skb with this
>>>>>> device, but some of the pointers and original data in the skb seem
>>>>>> totally off. This leaves me clueless as to where to put this
>>>>>> ieee80211_header.
>>>>>> I've tried putting it right on skb->head (wrong I know, but I was
>>>>>> getting desperate), on skb->mac_header (also wrong, no idea why
>>>>>> though), I went back from skb->tail with len and even added ETH_HLEN
>>>>>> to that as well because you can see that before my hook gets
>>>>>> activated: skb_pull_inline(skb, ETH_HLEN);
>>>>>> In the end I'm left with a header that is forced onto data but with a
>>>>>> wrong origin pointer thus basically leaving me with all wrong data in
>>>>>> the header.
>>>>>>
>>>>>> Kind regards,
>>>>>> Mathieu Devos
>>>>>>
>>>>>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel
>>>>>> <arend@broadcom.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I hope this is the right place to ask for a little bit of help as
>>>>>>>> I'm
>>>>>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>>>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>>>>>> to print information about the mac addresses (addr1->addr4) and
>>>>>>>> later
>>>>>>>> down the road try to send my own data.
>>>>>>>>
>>>>>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>>>>>> ieee80211 based on input from skb would be huge for me.
>>>>>>>>
>>>>>>>> So my issue: when placing the ieee80211 on my mac_header after I
>>>>>>>> hook
>>>>>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Not sure what you goal is, but what wireless device is that? You may
>>>>>>> just
>>>>>>> get 802.3 packets from the device.
>>>>>>>
>>>>>>> Gr. AvS
>>>>>>>
>>>>>>>
>>>>>>>> I get a huge
>>>>>>>> amount of zero's and random(?) numbers when trying to print the
>>>>>>>> addresses. This leads me to the first conclusion that mac_header is
>>>>>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>>>>>> using the skb->data pointer. Now this gives even weirder issues for
>>>>>>>> me
>>>>>>>> and actually totally crashes my kernel.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] rtlwifi: sparse warnings: cast to restricted type
From: Larry Finger @ 2013-07-31 17:21 UTC (permalink / raw)
To: Mark Schulte; +Cc: linville, linux-wireless
In-Reply-To: <1375254507-26154-2-git-send-email-schultetwin@gmail.com>
On 07/31/2013 02:08 AM, Mark Schulte wrote:
> Adding type casts to suppress sparse warnings:
> * warning: cast to restricted __le32/__le16
>
> Signed-off-by: Mark Schulte <schultetwin@gmail.com>
> ---
> drivers/net/wireless/rtlwifi/ps.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
I think this patch is OK, but until I get a chance to test it on a big-endian
machine (PowerBook G4 Titanium), please do not apply it.
When I tried the patch, I discovered some kind of regression that causes a
kernel oops with an RTL8192CU device installed. This patch is not the problem,
but I will need to bisect the oops before I can test. The machine takes a long
time to build each kernel, thus it will probably be a while.
Larry
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Chris Wright @ 2013-07-31 17:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Chris Wright, linux-wireless, Derek Atkins
In-Reply-To: <20130731132625.GA23521@sequoia2.sous-sol.org>
* Chris Wright (chrisw@sous-sol.org) wrote:
> while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
> IEEE80211_CHAN_DISABLED)) {
> if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
> ret = IEEE80211_STA_DISABLE_HT |
> IEEE80211_STA_DISABLE_VHT;
> goto out;
> }
Actually, it just looks like this above loop is broken. Code flow is:
chandef->width = NL80211_CHAN_WIDTH_20;
...
if (!vht_oper || !sband->vht_cap.vht_supported) {
ret = IEEE80211_STA_DISABLE_VHT;
goto out;
}
...
out:
/* don't print the message below for VHT mismatch if VHT is disabled */
if (ret & IEEE80211_STA_DISABLE_VHT)
vht_chandef = *chandef;
while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
goto out;
}
ret |= chandef_downgrade(chandef);
}
We enter the while loop w/ width NL80211_CHAN_WIDTH_20
(i.e. ht_cap.ht_supported is true), do one downgrade to
NL80211_CHAN_WIDTH_20_NOHT, and then we are stuck in a permanent loop.
I did not see any way that cfg80211_chandef_usable() will update chandef->width
so once width is NL80211_CHAN_WIDTH_20_NOHT and ht_cap.ht_supported is
true there is no end to the goto loop.
So here is a hack that at least gets wireless working (only because
there's another AP that's not got 11n enabled I believe).
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0e5aab1..b68ca05 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -336,7 +336,7 @@ out:
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
- goto out;
+ break;
}
ret |= chandef_downgrade(chandef);
^ permalink raw reply related
* Intel WiFi Link 4965AGN - Failed, HW not ready
From: Abdur Rehman @ 2013-07-31 17:52 UTC (permalink / raw)
To: linux-wireless, ilw
Hi we are unable to load the driver for Intel 4965agn module on a linux
system.
We are seeing "HW not ready" error. Please see the log below
modprobe iwlagn
[ 54.690000] cfg80211: Using static regulatory domain info
[ 54.700000] cfg80211: Regulatory domain: US
[ 54.710000] (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
[ 54.720000] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 54.730000] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.740000] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.750000] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.760000] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.770000] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 54.780000] cfg80211: Calling CRDA for country: US
[ 55.080000] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
1.3.27k
[ 55.090000] iwlagn: Copyright(c) 2003-2009 Intel Corporation
[ 55.100000] PCI: enabling device 0000:04:00.0 (0000 -> 0002)
[ 55.110000] iwlagn 0000:04:00.0: Detected Intel Wireless WiFi Link
4965AGN REV=0x0
[ 55.120000] iwlagn 0000:04:00.0: Failed, HW not ready
^ permalink raw reply
* Re: Intel WiFi Link 4965AGN - Failed, HW not ready
From: Sedat Dilek @ 2013-07-31 18:06 UTC (permalink / raw)
To: Abdur Rehman; +Cc: linux-wireless, ilw
In-Reply-To: <51F94EEA.8040503@gespk.com>
On Wed, Jul 31, 2013 at 7:52 PM, Abdur Rehman <arqureshi@gespk.com> wrote:
> Hi we are unable to load the driver for Intel 4965agn module on a linux
> system.
> We are seeing "HW not ready" error. Please see the log below
>
Hi,
can't say who is "we"... but /me sees no Linux-kernel version!
Attach a full dmesg - it does not hurt together with your kernel-config file?
Do you have installed a firmware? What firmware-version do you use?
... (have a look into docs on <wireless.kernel.org>?)...
Make "we" "us" "you" "me" $(hello-)world happy :-)!
- Sedat -
> modprobe iwlagn
> [ 54.690000] cfg80211: Using static regulatory domain info
> [ 54.700000] cfg80211: Regulatory domain: US
> [ 54.710000] (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> [ 54.720000] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> [ 54.730000] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.740000] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.750000] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.760000] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.770000] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> [ 54.780000] cfg80211: Calling CRDA for country: US
> [ 55.080000] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
> 1.3.27k
> [ 55.090000] iwlagn: Copyright(c) 2003-2009 Intel Corporation
> [ 55.100000] PCI: enabling device 0000:04:00.0 (0000 -> 0002)
> [ 55.110000] iwlagn 0000:04:00.0: Detected Intel Wireless WiFi Link 4965AGN
> REV=0x0
> [ 55.120000] iwlagn 0000:04:00.0: Failed, HW not ready
> --
> 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: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Ben Greear @ 2013-07-31 18:13 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Paul Stewart, Felix Fietkau, Jouni Malinen
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On 07/30/2013 05:53 PM, Luis R. Rodriguez wrote:
> Folks,
>
> Back in 2009 Intel had put out a wifi-test tree [0] but that seems
> deprecated now. The git tree at least is gone. Can someone confirm if
> that's dead? We later had Google present at the 2010 San Francisco
> wireless summit [1] their test infrastructure using autotest. Last I
> checked that stuff was not merged back upstream to autotest. Can
> someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
> internal testing infrastructures that obviously are not open.
>
> If we are to embark on a new journey towards an open testing
> infrastructure what should be used? Ben, you have some stuff, and I
> know you also report some interesting bugs with insane amount of
> stations. Is any of it open?
Our user-space app is not open. I'm happy to offer free licenses
for good causes, but I understand that is probably not so interesting to most
folks.
Our stuff only really works with ath9k (and possibly ath5k). Might
work in the future with ath10k if we can get the firmware and other
limitations resolved. And, maybe some other vendors will start
supporting lots of virtual stations..but I don't know of any others
at this time.
At the least, we'll keep running our internal testing & dev efforts
and will continue to report strange bugs :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* CLI scan tool needed
From: Michael McElroy @ 2013-07-31 18:27 UTC (permalink / raw)
To: linux-wireless
I've done a lot of searching before posting but can't seem to find the answer.
Using the backports project, I have one of the latest ralink driver
going on an arm processor running 2.6.29 along with all nl80211 parts.
Works great, thank you! The last piece I need is to get the to SSID
list, their security protocols, and signal strength. I'm looking for
output similar to 'wilist scanning'. 'iw scan' gives a lot of info but
not quite what I need without a lot of massaging.
GUI based utilities won't work for my environment.Can anyone give me
some suggestions where to look?
Thanks,
Mike
^ permalink raw reply
* [PATCH 3.11] cfg80211: fix P2P GO interface teardown
From: Johannes Berg @ 2013-07-31 19:02 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When a P2P GO interface goes down, cfg80211 doesn't properly
tear it down, leading to warnings later. Add the GO interface
type to the enumeration to tear it down like AP interfaces.
Otherwise, we leave it pending and mac80211's state can get
very confused, leading to warnings later.
Cc: stable@vger.kernel.org
Reported-by: Ilan Peer <ilan.peer@intel.com>
Tested-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 4f9f216..a8c29fa4 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -765,6 +765,7 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev,
cfg80211_leave_mesh(rdev, dev);
break;
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_P2P_GO:
cfg80211_stop_ap(rdev, dev);
break;
default:
--
1.8.0
^ permalink raw reply related
* [PATCH 3.11] mac80211: continue using disabled channels while connected
From: Johannes Berg @ 2013-07-31 19:09 UTC (permalink / raw)
To: linux-wireless; +Cc: chrisw, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
In case the AP has different regulatory information than we do,
it can happen that we connect to an AP based on e.g. the world
roaming regulatory data, and then update our database with the
AP's country information disables the channel the AP is using.
If this happens on an HT AP, the bandwidth tracking code will
hit the WARN_ON() and disconnect. Since that's not very useful,
ignore the channel-disable flag in bandwidth tracking.
Reported-by: Chris Wright <chrisw@sous-sol.org>
Tested-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 77e7796..3df4fb3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -335,8 +335,17 @@ out:
if (ret & IEEE80211_STA_DISABLE_VHT)
vht_chandef = *chandef;
+ /*
+ * Ignore the DISABLED flag when we're already connected and only
+ * tracking the APs beacon for bandwidth changes - otherwise we
+ * might get disconnected here if we connect to an AP, update our
+ * regulatory information based on the AP's country IE and the
+ * information we have is wrong/outdated and disables the channel
+ * that we're actually using for the connection to the AP.
+ */
while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
- IEEE80211_CHAN_DISABLED)) {
+ tracking ? 0 :
+ IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 3.11] mac80211: continue using disabled channels while connected
From: Johannes Berg @ 2013-07-31 19:10 UTC (permalink / raw)
To: linux-wireless; +Cc: chrisw
In-Reply-To: <1375297799-2023-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 21:09 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> In case the AP has different regulatory information than we do,
> it can happen that we connect to an AP based on e.g. the world
> roaming regulatory data, and then update our database with the
> AP's country information disables the channel the AP is using.
> If this happens on an HT AP, the bandwidth tracking code will
> hit the WARN_ON() and disconnect. Since that's not very useful,
> ignore the channel-disable flag in bandwidth tracking.
>
> Reported-by: Chris Wright <chrisw@sous-sol.org>
> Tested-by: Chris Wright <chrisw@sous-sol.org>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Forgot Cc stable, will add.
johannes
^ permalink raw reply
* [PATCH] mac80211: fix infinite loop in ieee80211_determine_chantype
From: Chris Wright @ 2013-07-31 19:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: Chris Wright, linux-wireless, Derek Atkins
In-Reply-To: <20130731132625.GA23521@sequoia2.sous-sol.org>
Commit "3d9646d mac80211: fix channel selection bug" introduced a possible
infinite loop by moving the out target above the chandef_downgrade
while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
back up to re-run the while loop...indefinitely. Replace goto with
break and carry on. This may not be sufficient to connect to the AP,
but will at least keep the cpu from livelocking. Thanks to Derek Atkins
as an extra pair of debugging eyes.
Cc: stable@kernel.org
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0e5aab1..b68ca05 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -336,7 +336,7 @@ out:
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
- goto out;
+ break;
}
ret |= chandef_downgrade(chandef);
^ permalink raw reply related
* Re: pull request: bluetooth 2013-07-30
From: John W. Linville @ 2013-07-31 19:08 UTC (permalink / raw)
To: Gustavo Padovan, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20130730123848.GE5975@joana>
On Tue, Jul 30, 2013 at 01:38:48PM +0100, Gustavo Padovan wrote:
> Hi John,
>
> A few fixes and devices ID additions for 3.11:
>
> * There are 4 new ath3k device ids
> * Fixed stack memory usage in ath3k.
> * Fixed the init process of BlueFRITZ! devices, they were failing to init
> due to an unsupported command we sent.
> * Fixed wrong use of PTR_ERR in btusb code that was preventing intel devices
> to work properly.
> * Fixed race condition between hci_register_dev() and hci_dev_open() that
> could cause a NULL pointer dereference.
> * Fixed race condition that could call hci_req_cmd_complete() and make some
> devices to fail as showed in the log added to the commit message.
>
> Please pull or let me know of any issues. Thanks.
>
> Gustavo
>
> --
> The following changes since commit 075163bbb0f51174359947e1bce84f5edb23f21e:
>
> ath9k_htc: Handle IDLE state transition properly (2013-06-24 13:52:52 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
>
> for you to fetch changes up to 53e21fbc288218a423959f878c86471a0e323a9a:
>
> Bluetooth: Fix calling request callback more than once (2013-07-29 12:28:04 +0100)
Pulling now...
--
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] mac80211: fix infinite loop in ieee80211_determine_chantype
From: Johannes Berg @ 2013-07-31 19:15 UTC (permalink / raw)
To: Chris Wright; +Cc: linux-wireless, Derek Atkins
In-Reply-To: <20130731191224.GB28308@sequoia2.sous-sol.org>
On Wed, 2013-07-31 at 12:12 -0700, Chris Wright wrote:
> Commit "3d9646d mac80211: fix channel selection bug" introduced a possible
> infinite loop by moving the out target above the chandef_downgrade
> while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
> back up to re-run the while loop...indefinitely. Replace goto with
> break and carry on. This may not be sufficient to connect to the AP,
> but will at least keep the cpu from livelocking. Thanks to Derek Atkins
> as an extra pair of debugging eyes.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: continue using disabled channels while connected
From: Johannes Berg @ 2013-07-31 19:17 UTC (permalink / raw)
To: linux-wireless; +Cc: chrisw
In-Reply-To: <1375297799-2023-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 21:09 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> In case the AP has different regulatory information than we do,
> it can happen that we connect to an AP based on e.g. the world
> roaming regulatory data, and then update our database with the
> AP's country information disables the channel the AP is using.
> If this happens on an HT AP, the bandwidth tracking code will
> hit the WARN_ON() and disconnect. Since that's not very useful,
> ignore the channel-disable flag in bandwidth tracking.
Applied.
(ok, so this was a short time, but it's kinda an important fix ...)
johannes
^ permalink raw reply
* Re: [PATCH 3.11] cfg80211: fix P2P GO interface teardown
From: Johannes Berg @ 2013-07-31 19:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1375297347-1380-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 21:02 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> When a P2P GO interface goes down, cfg80211 doesn't properly
> tear it down, leading to warnings later. Add the GO interface
> type to the enumeration to tear it down like AP interfaces.
> Otherwise, we leave it pending and mac80211's state can get
> very confused, leading to warnings later.
Applied
(it's obvious and we've tested it for a while)
johannes
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: don't wait for TX status forever
From: Johannes Berg @ 2013-07-31 19:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1375258961-26321-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 10:22 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> TX status notification can get lost, or the frames could
> get stuck on the queue, so don't wait for the callback
> from the driver forever and instead time out after half
> a second.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Johannes Berg @ 2013-07-31 19:18 UTC (permalink / raw)
To: linux-wireless; +Cc: Arkadiusz Miskiewicz, Andy Isaacson, Stanislaw Gruszka
In-Reply-To: <1375264234-31077-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 11:50 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> While we're connected, the AP shouldn't change the primary channel
> in the HT information. We checked this, and dropped the connection
> if it did change it.
>
> Unfortunately, this is causing problems on some APs, e.g. on the
> Netgear WRT610NL: the beacons seem to always contain a bad channel
> and if we made a connection using a probe response (correct data)
> we drop the connection immediately and can basically not connect
> properly at all.
>
> Work around this by ignoring the HT primary channel information in
> beacons if we're already connected.
>
> Also print out more verbose messages in the other situations to
> help diagnose similar bugs quicker in the future.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 3.11] cfg80211: fix P2P GO interface teardown
From: Arend van Spriel @ 2013-07-31 19:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1375298245.8289.19.camel@jlt4.sipsolutions.net>
On 07/31/2013 09:17 PM, Johannes Berg wrote:
> On Wed, 2013-07-31 at 21:02 +0200, Johannes Berg wrote:
>> From: Johannes Berg <johannes.berg@intel.com>
>>
>> When a P2P GO interface goes down, cfg80211 doesn't properly
>> tear it down, leading to warnings later. Add the GO interface
>> type to the enumeration to tear it down like AP interfaces.
>> Otherwise, we leave it pending and mac80211's state can get
>> very confused, leading to warnings later.
>
> Applied
>
> (it's obvious and we've tested it for a while)
We'll see what happens when I test it with brcmfmac :-p
Gr. AvS
^ permalink raw reply
* pull-request: mac80211 2013-07-31
From: Johannes Berg @ 2013-07-31 19:25 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
John,
Another pull request for mac80211 - this time with a bunch of important
fixes.
I have a fix from Chris for an infinite loop along with fixes from
myself to prevent it entering the loop to start with (continue using
disabled channels, many thanks to Chris for his debug/test help) and a
workaround for broken APs that advertise a bad HT primary channel in
their beacons. Additionally, a fix for another attrbuf race in mac80211
and a fix to clean up properly while P2P GO interfaces go down.
Let me know if there's any problem.
johannes
The following changes since commit 23df0b731954502a9391e739b92927cee4360343:
regulatory: use correct regulatory initiator on wiphy register (2013-07-25 09:52:46 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
for you to fetch changes up to ddfe49b42d8ad4bfdf92d63d4a74f162660d878d:
mac80211: continue using disabled channels while connected (2013-07-31 21:18:17 +0200)
----------------------------------------------------------------
Chris Wright (1):
mac80211: fix infinite loop in ieee80211_determine_chantype
Johannes Berg (5):
nl80211: fix another nl80211_fam.attrbuf race
mac80211: don't wait for TX status forever
mac80211: ignore HT primary channel while connected
cfg80211: fix P2P GO interface teardown
mac80211: continue using disabled channels while connected
net/mac80211/mlme.c | 54 +++++++++++++++++++++++++++++++++-----------------
net/wireless/core.c | 1 +
net/wireless/nl80211.c | 6 ++++--
3 files changed, 41 insertions(+), 20 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 3.11] cfg80211: fix P2P GO interface teardown
From: Johannes Berg @ 2013-07-31 19:26 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F9632B.8090105@broadcom.com>
On Wed, 2013-07-31 at 21:19 +0200, Arend van Spriel wrote:
> On 07/31/2013 09:17 PM, Johannes Berg wrote:
> > On Wed, 2013-07-31 at 21:02 +0200, Johannes Berg wrote:
> >> From: Johannes Berg <johannes.berg@intel.com>
> >>
> >> When a P2P GO interface goes down, cfg80211 doesn't properly
> >> tear it down, leading to warnings later. Add the GO interface
> >> type to the enumeration to tear it down like AP interfaces.
> >> Otherwise, we leave it pending and mac80211's state can get
> >> very confused, leading to warnings later.
> >
> > Applied
> >
> > (it's obvious and we've tested it for a while)
>
> We'll see what happens when I test it with brcmfmac :-p
Do you even know how to test it? ;-)
Normally we don't go into this code path because wpa_supplicant will
properly clean up before removing the GO interface - we only saw it with
rfkill and/or doing 'ip link set wlan0-p2p-0 down' or so.
johannes
^ permalink raw reply
* Re: [GIT] [NFC] 3.11 fixes
From: John W. Linville @ 2013-07-31 19:15 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Linux Wireless, Linux NFC
In-Reply-To: <20130730235915.GA4641@zurbaran>
On Wed, Jul 31, 2013 at 01:59:15AM +0200, Samuel Ortiz wrote:
> Hi John,
>
> This is the second NFC fixes pull request for 3.11.
>
> We have:
>
> 1) A build failure fix for the NCI SPI transport layer due to a
> missing CRC_CCITT Kconfig dependency.
>
> 2) A netlink command rename: CMD_FW_UPLOAD was merged during the 3.11
> merge window but the typical terminology for loading a firmware to a
> target is firmware download rather than upload. In order to avoid any
> confusion in a file exported to userspace, we rename this command to
> CMD_FW_DOWNLOAD.
>
> I realize 2) might not meet the net.git criteria for what fixes are. If
> you don't want to take it then I'll have to push it through the
> 3.12 merge window. If that's the case, and you only want to take 1) then
> please use tags/nfc-3.11-1 instead of tags/nfc-3.11-2 in your pull URL.
>
> The following changes since commit 64b6f46f1141ad938e354f37af62e28da972e8eb:
>
> ath9k_hw: Fix multicast search for AR9002 family (2013-07-18 16:22:00 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes.git tags/nfc-fixes-3.11-2
>
> for you to fetch changes up to 9ea7187c53f63e31f2d1b2b1e474e31808565009:
>
> NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD (2013-07-31 01:19:43 +0200)
Pulling now...
--
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] mac80211: implement critical protocol protection
From: Arik Nemtsov @ 2013-07-31 19:59 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1374826090-17322-1-git-send-email-johannes@sipsolutions.net>
On Fri, Jul 26, 2013 at 11:08 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>
> This new API add in cfg80211 wasn't implemented in mac80211.
> Advertise the capabilities based on the device's
> implementation (possibly NULL) of crit_prot mac80211 ops.
>
> This callback will be called by cfg80211 when hinted by
> userspace that a critical protocol is happening, e.g. it can
> be EAPOL, DHCP.
>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[...]
> +static int ieee80211_crit_proto_start(struct wiphy *wiphy,
> + struct wireless_dev *wdev,
> + enum nl80211_crit_proto_id protocol,
> + u16 duration)
> +{
> + struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
> + struct ieee80211_local *local = wiphy_priv(wiphy);
> + int ret;
> +
> + ret = drv_crit_proto(local, sdata, protocol, true);
> + if (!ret)
> + return ret;
Shouldn't this be "if (ret)" ?
Also maybe the low-level driver should get the duration and indicate
completion on its own? (similar to what Eliad suggested).
Seems to me very similar to ROC, and would probably be implemented as
such for some drivers.
> +
> + ieee80211_queue_delayed_work(&sdata->local->hw,
> + &sdata->crit_prot_end_wk,
> + msecs_to_jiffies(duration));
> + return 0;
> +}
Arik
^ permalink raw reply
* Re: CLI scan tool needed
From: Krishna Chaitanya @ 2013-07-31 20:30 UTC (permalink / raw)
To: Michael McElroy; +Cc: linux-wireless
In-Reply-To: <CAJt7DwytQzEMzn9way1z5ag-vo=GsYF72uvmAJEcJeJs=Y-hfw@mail.gmail.com>
On Wed, Jul 31, 2013 at 11:57 PM, Michael McElroy <mikem388@gmail.com> wrote:
> Using the backports project, I have one of the latest ralink driver
> going on an arm processor running 2.6.29 along with all nl80211 parts.
> Works great, thank you! The last piece I need is to get the to SSID
> list, their security protocols, and signal strength. I'm looking for
> output similar to 'wilist scanning'. 'iw scan' gives a lot of info but
> not quite what I need without a lot of massaging.
"wpa_cli -i <interface> scan"
this should give you the required info, if you are already running the
wpa_supplicant.
^ permalink raw reply
* Re: CLI scan tool needed
From: Michael McElroy @ 2013-07-31 20:51 UTC (permalink / raw)
To: Krishna Chaitanya; +Cc: linux-wireless
In-Reply-To: <CABPxzYJQB_Lsi4aYkSfvULEgToECAdfZfJCtpm1u4Fo7ibc02g@mail.gmail.com>
Thanks Krishna, but all it returns is OK. Running the version 2.0 of
wpa_supplicant.
On Wed, Jul 31, 2013 at 4:30 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Wed, Jul 31, 2013 at 11:57 PM, Michael McElroy <mikem388@gmail.com> wrote:
>> Using the backports project, I have one of the latest ralink driver
>> going on an arm processor running 2.6.29 along with all nl80211 parts.
>> Works great, thank you! The last piece I need is to get the to SSID
>> list, their security protocols, and signal strength. I'm looking for
>> output similar to 'wilist scanning'. 'iw scan' gives a lot of info but
>> not quite what I need without a lot of massaging.
>
> "wpa_cli -i <interface> scan"
> this should give you the required info, if you are already running the
> wpa_supplicant.
^ 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