* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 19:33 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1FA76.3090109@rempel-privat.de>
On Wed, Jun 19, 2013 at 08:37:42PM +0200, thus spake Oleksij Rempel:
> Can you please tell more about your access point:
> - hardware
> - firmware
> - configuration
> - "iw dev wlan0 scan dump"
I tested the thing with at least three different APs:
- Netgear DG834Gv4 with latest firmware.
- Netgear DG834Gv5 (don't know which firmware and can't check at this time).
- hostapd (can't say which version at this time either) with the same
ath9k_htc.
All APs are configured for WPA2-PSK.
The scan dump for the first AP:
BSS 00:1e:2a:ed:35:70 (on wlan7)
TSF: 163623606 usec (0d, 00:02:43)
freq: 2412
beacon interval: 100
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -43.00 dBm
last seen: 24 ms ago
Information elements from Probe Response frame:
SSID: Wolfnet
Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0
DS Parameter set: channel 1
ERP: Barker_Preamble_Mode
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 16-PTKSA-RC (0x000c)
Extended supported rates: 6.0 9.0 12.0 48.0
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
--
Save the whales. Feed the hungry. Free the mallocs.
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Rafał Miłecki @ 2013-06-19 19:30 UTC (permalink / raw)
To: Rafał Miłecki, Larry Finger, b43-dev, linux-wireless
In-Reply-To: <20130619175850.GD4784@cmadams.net>
2013/6/19 Chris Adams <cma@cmadams.net>:
> Once upon a time, Rafał Miłecki <zajec5@gmail.com> said:
>> I don't know how/if driver can be responsible for such reconnects.
>> Over all it just TX and RX packets, right? Loosing a signal is
>> something different, that can be related to the driver's bug. But as
>> this happens every 5 minutes... I don't know.
>>
>> Did you try connecting to this AP with any other card and using
>> similar kernel? I wonder if this can be some supplicant / mac80211
>> stack issue...
>
> I just fired up my Thinkpad T510 with an Intel "Centrino Ultimate-N
> 6300" using iwlwifi, and it stays connected (does not appear to drop any
> packets). This is also Fedora 18 x86_64 (slightly older kernel, but
> I've had the problem on the MacBook since I installed it). There are
> other people in the office with the same MacBook hardware (but running
> OS X) that don't appear to be having any trouble either.
>
> The AP appears to be an Adtran (don't know the model).
Thanks for info/testing. I still wonder how driver's code can cause
any disconnections happening exactly every 5 minutes... Any idea
anyone?
One bug that was recently discovered and that sits in b43's code is
passive scanning. For some reason it seems b43 doesn't do passive
scanning, I didn't have time to debug that yet. I wonder if this can
affect connection stability anyhow.
Perhaps you could try performing manual scanning every ~minute? It's
really just a crazy guess, I don't have any idea why it could help.
But it's so trivial you may want to give it a try.
--
Rafał
^ permalink raw reply
* Re: [PATCH mac80211-next] brcm80211: fix null pointer access
From: John W. Linville @ 2013-06-19 19:27 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: Johannes Berg, linux-wireless, Antonio Quartulli
In-Reply-To: <1371641731-1297-1-git-send-email-ordex@autistici.org>
FWIW, driver fixes like this come to me rather than Johannes...
On Wed, Jun 19, 2013 at 01:35:31PM +0200, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> Do not unconditionally access the chan variable in
> brcmf_cfg80211_mgmt_tx() as it may be NULL.
> Use freq instead.
>
> Introduced by c2ff8cad64233b539c71a27e2a6e324001143ef0
> ("brcm80211: make mgmt_tx in brcmfmac accept a NULL channel")
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> index 8bd256b..d316d62 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> @@ -3985,8 +3985,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> le16_to_cpu(action_frame->len));
>
> brcmf_dbg(TRACE, "Action frame, cookie=%lld, len=%d, freq=%d\n",
> - *cookie, le16_to_cpu(action_frame->len),
> - chan->center_freq);
> + *cookie, le16_to_cpu(action_frame->len), freq);
>
> ack = brcmf_p2p_send_action_frame(cfg, cfg_to_ndev(cfg),
> af_params);
> --
> 1.8.1.5
>
> --
> 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
>
--
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: pull-request: mac80211 2013-06-19
From: John W. Linville @ 2013-06-19 19:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1371659691.8349.24.camel@jlt4.sipsolutions.net>
On Wed, Jun 19, 2013 at 06:34:51PM +0200, Johannes Berg wrote:
> Hi John,
>
> One more ...
>
> This is just the fix for the nl80211_fam.attrbuf race Linus ran into and
> analysed.
>
> johannes
>
> The following changes since commit 795d855d56c6d172f50a974f603ba923ac93ee76:
>
> mac80211: Fix rate control mask matching call (2013-06-12 09:12:43 +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 3a5a423bb958ad22eeccca66c533e85bf69ba10e:
>
> nl80211: fix attrbuf access race by allocating a separate one (2013-06-19 18:31:20 +0200)
>
> ----------------------------------------------------------------
> Johannes Berg (1):
> nl80211: fix attrbuf access race by allocating a separate one
>
> net/wireless/nl80211.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
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: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 18:55 UTC (permalink / raw)
To: Ben Greear
Cc: Ignacy Gawedzki, Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1FAFB.9090209@candelatech.com>
Am 19.06.2013 20:39, schrieb Ben Greear:
> On 06/19/2013 11:37 AM, Oleksij Rempel wrote:
>>
>>
>> Am 19.06.2013 20:03, schrieb Ignacy Gawedzki:
>>> On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
>>>> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
>>>>> Ignacy, Is it RPi + TL-WN722NC?
>>>>
>>>> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu
>>>> 13.04).
>>>
>>> BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.
>>
>> Can you please tell more about your access point:
>> - hardware
>> - firmware
>> - configuration
>> - "iw dev wlan0 scan dump"
>
> Does the ath9k_htc do it's own rate control, perhaps modelled on
> ath9k_rate_control
> algorithm?
>
> If so, that could be the problem...it has issues with associating when
> network conditions are poor...
uff... yeah... we can't do comparison test :( except just come closer to AP.
--
Regards,
Oleksij
^ permalink raw reply
* Re: Howto remove rfkill from kernel
From: John W. Linville @ 2013-06-19 18:38 UTC (permalink / raw)
To: rlwkayaker; +Cc: linux-wireless
In-Reply-To: <20130619133638.3d183a00@compuzoo>
On Wed, Jun 19, 2013 at 01:36:38PM -0400, rlwkayaker wrote:
> The rfkill "feature" has rendered the internal wireless of my
> Averatec 3260 laptop unusable. It works fine with earlier
> kernels without this "feature". How do I remove the rfkill
> "feature" from a custom built kernel?
The rfkill "feature" has been in the kernel for years. Exactly what
kernels are you using?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Corey Richardson @ 2013-06-19 18:44 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Johannes Berg, Ignacy Gawedzki, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <51C1FA33.2050308@rempel-privat.de>
On Wed, Jun 19, 2013 at 2:36 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Every thing about your old WAP and symptoms of problems you had.
> - hardware. also you ath9k_htc adapter too
The adapter is a netgear WNA1100. The WAP actually died,
unfortunately, it will no longer boot up, and I no longer have it, but
it was an HP ProCurve something-or-another.
Sorry I can't be more useful :(
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ben Greear @ 2013-06-19 18:39 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Ignacy Gawedzki, Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1FA76.3090109@rempel-privat.de>
On 06/19/2013 11:37 AM, Oleksij Rempel wrote:
>
>
> Am 19.06.2013 20:03, schrieb Ignacy Gawedzki:
>> On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
>>> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
>>>> Ignacy, Is it RPi + TL-WN722NC?
>>>
>>> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
>>
>> BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.
>
> Can you please tell more about your access point:
> - hardware
> - firmware
> - configuration
> - "iw dev wlan0 scan dump"
Does the ath9k_htc do it's own rate control, perhaps modelled on ath9k_rate_control
algorithm?
If so, that could be the problem...it has issues with associating when
network conditions are poor...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 18:37 UTC (permalink / raw)
To: Ignacy Gawedzki, Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <20130619180354.GB19405@zenon.in.qult.net>
Am 19.06.2013 20:03, schrieb Ignacy Gawedzki:
> On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
>> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
>>> Ignacy, Is it RPi + TL-WN722NC?
>>
>> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
>
> BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.
Can you please tell more about your access point:
- hardware
- firmware
- configuration
- "iw dev wlan0 scan dump"
--
Regards,
Oleksij
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 18:36 UTC (permalink / raw)
To: Corey Richardson
Cc: Johannes Berg, Ignacy Gawedzki, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <CA++BO6Rsys5Q_Wxuhcm+00uMvJq3HF2GcU7LmuVsYWq_BW-svw@mail.gmail.com>
Am 19.06.2013 17:11, schrieb Corey Richardson:
> On Wed, Jun 19, 2013 at 11:08 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 19.06.2013 16:11, schrieb Johannes Berg:
>>>
>>> Btw, I'm a bit confused -- are you using ath9k_htc as per the subject,
>>> or ath9k?
>>>
>>> if it's ath9k_htc then I don't really understand why the patch that
>>> *fixed* it for Corey *broke* it for you?
>>>
>>> johannes
>>
>>
>> It will be interesting to get some more info from Corey, about his wireless
>> setup.
>>
>
> It seems many of my issues were related to a faulty WAP, once I
> replaced it with a different one 90% of my problems went away. What
> information do you want?
Every thing about your old WAP and symptoms of problems you had.
- hardware. also you ath9k_htc adapter too
- firmware
- configuration
- "iw dev wlan0 scan dump"
Currently we have diffetrent mystical bugs, which are impossible to
reproduce some where else. So we will just collect every information we
can find.
--
Regards,
Oleksij
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Chris Adams @ 2013-06-19 17:58 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Larry Finger, b43-dev, linux-wireless
In-Reply-To: <CACna6rzbTHnyqs5SzTuYL7r_SW3iCNh0qqbnvfsF7Wspyhp1WA@mail.gmail.com>
Once upon a time, Rafał Miłecki <zajec5@gmail.com> said:
> I don't know how/if driver can be responsible for such reconnects.
> Over all it just TX and RX packets, right? Loosing a signal is
> something different, that can be related to the driver's bug. But as
> this happens every 5 minutes... I don't know.
>
> Did you try connecting to this AP with any other card and using
> similar kernel? I wonder if this can be some supplicant / mac80211
> stack issue...
I just fired up my Thinkpad T510 with an Intel "Centrino Ultimate-N
6300" using iwlwifi, and it stays connected (does not appear to drop any
packets). This is also Fedora 18 x86_64 (slightly older kernel, but
I've had the problem on the MacBook since I installed it). There are
other people in the office with the same MacBook hardware (but running
OS X) that don't appear to be having any trouble either.
The AP appears to be an Adtran (don't know the model).
--
Chris Adams <cma@cmadams.net>
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 18:03 UTC (permalink / raw)
To: Oleksij Rempel, Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <20130619175939.GA19405@zenon.in.qult.net>
On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
> > Ignacy, Is it RPi + TL-WN722NC?
>
> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.
--
Everything is more fun naked except cooking with grease.
^ permalink raw reply
* Howto remove rfkill from kernel
From: rlwkayaker @ 2013-06-19 17:36 UTC (permalink / raw)
To: linux-wireless
The rfkill "feature" has rendered the internal wireless of my
Averatec 3260 laptop unusable. It works fine with earlier
kernels without this "feature". How do I remove the rfkill
"feature" from a custom built kernel?
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 17:59 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1C95C.8030301@rempel-privat.de>
On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
> Ignacy wrote:
> >The station is unable to authenticate with WPA2 to the AP. Interestingly
> >enough, if a monitor vif is created and upped beforehand, the authentication
> >succeeds.
>
> which looks more like power management issue. If monitore mode is
> enabled, no power sawing is done. But i use CFG80211_DEFAULT_PS=y on
> my system too and didn't had this issue. Even power_save=on is
> working. What else is different?
>
> Ignacy, Is it RPi + TL-WN722NC?
Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
--
P.S. All information contained in the above letter is false,
for reasons of military security.
^ permalink raw reply
* Re: Re: bug-report: Ralink corp. Device [1814:539a] - Kernel 3.8 +
From: Lars Zastrow @ 2013-06-19 17:59 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: backports, linux-wireless
In-Reply-To: <20130619131234.GB2580@redhat.com>
Am 19.06.2013 15:12, schrieb Stanislaw Gruszka:
> On Mon, Jun 17, 2013 at 05:18:32AM +0200, Lars Zastrow wrote:
>> Dear Team,
>>
>> I'am using the following wireless-network-device:
>>
>> Network controller [0280]: Ralink corp. Device [1814:539a]
>> Subsystem: Hewlett-Packard Company Device [103c:1839]
>> Kernel driver in use: rt2800pci
>>
>> I had problems with it since I bought my laptop... The driver was
>> unstable with the kernel I used back in autumn 2012. Howeverer, one
>> kernel-update fixed it. Must be something about 3.4x?
>>
>> It was defenetly working with the Kernels from 3.5 till 3.7 on
>> multible distros. 3.8 was bringing back the old Problems:
>>
>> - extremly low signal
>> - hard to establish a connection to any acess-point.
>>
>> The last "problematic" kernel I have testet was 3.9.5-1 on
>> Arch-Linux. Compiling the compat-drivers manually did not bring any
>> fix.
>>
>> I am currently using 3.7.4-1 wich is working.
> This most likely is a RT5390 TX power problem I made on 3.8.
>
> This patch should help:
> https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=8c8d2017ba25c510ddf093419048460db1109bc4
>
> Stanislaw
Yes, indeed! It helps.
Now it was possible to upgrade my kernel, without losing my
wireless-device to be usable. Thank you very much.
I'm afraid it is not a "flawless" experience.
On the git-page you mentioned:
> Once we implement proper TSSI tuning on 5390/3290 we can restore back
setting TX power by BBP_R1 register for those chips.
Is there any hope, that the driver will increase its performance one day?
...there are better chips on the market, that is for sure.
Regards
Lars Zastrow
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Ben Greear @ 2013-06-19 17:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Linux Wireless List
In-Reply-To: <1371661217.8349.26.camel@jlt4.sipsolutions.net>
On 06/19/2013 10:00 AM, Johannes Berg wrote:
> On Wed, 2013-06-19 at 09:57 -0700, Ben Greear wrote:
>> On 06/19/2013 01:23 AM, Johannes Berg wrote:
>>> From: Johannes Berg <johannes.berg@intel.com>
>>>
>>> Since my commit 3713b4e364, nl80211_dump_wiphy() uses the global
>
>> The commit mentioned above (3713b4e364) is in 3.9.6,
>
> It isn't according to my git. :-)
Ahh, I was thinking that if 'git show foo' showed it, it was in that branch,
but I suppose that is not actually the case.
Sorry about that.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Chris Adams @ 2013-06-19 16:42 UTC (permalink / raw)
To: Larry Finger; +Cc: b43-dev, linux-wireless
In-Reply-To: <51C1DDEB.3090701@lwfinger.net>
Once upon a time, Larry Finger <Larry.Finger@lwfinger.net> said:
> What type of encryption are you using? If it is a re-keying type
> such as TKIP, what is the interval? You should find that on the
> setup page of the access point.
I don't have access to the management of this particular AP (work
environment), but "iw dev wlan0 scan dump" says CCMP.
> BTW, your mailer is set up strangely. I get your address when I do a
> plain Reply, but a Reply All from Thunderbird only got the b43-dev
> mailing list. I had to add your address manually.
I'm using Mutt, which sets "Mail-Followup-To: <listaddr>" for configured
mailing lists. If you were just replying to the b43-dev list, a CC to
me isn't really needed (I subscribed before sending; didn't know if
non-subscribers were allowed to send messages).
--
Chris Adams <cmadams@cmadams.net>
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Johannes Berg @ 2013-06-19 17:00 UTC (permalink / raw)
To: Ben Greear; +Cc: Linux Wireless List
In-Reply-To: <51C1E2FF.3030309@candelatech.com>
On Wed, 2013-06-19 at 09:57 -0700, Ben Greear wrote:
> On 06/19/2013 01:23 AM, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > Since my commit 3713b4e364, nl80211_dump_wiphy() uses the global
> The commit mentioned above (3713b4e364) is in 3.9.6,
It isn't according to my git. :-)
johannes
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Rafał Miłecki @ 2013-06-19 16:57 UTC (permalink / raw)
To: Larry Finger, b43-dev, linux-wireless
In-Reply-To: <20130619164227.GC4784@cmadams.net>
2013/6/19 Chris Adams <cmadams@cmadams.net>:
> Once upon a time, Larry Finger <Larry.Finger@lwfinger.net> said:
>> What type of encryption are you using? If it is a re-keying type
>> such as TKIP, what is the interval? You should find that on the
>> setup page of the access point.
>
> I don't have access to the management of this particular AP (work
> environment), but "iw dev wlan0 scan dump" says CCMP.
I think some key interval applies not only to the TKIP, but also other
keys. For example GTK (which is part of WPA2 with it's 4-way
handshake). GTK is Group Temporal Key, and Broadcom's router have a
setting called "GTK rotation interval". I guess PMK/PTK also can have
some intervals.
I don't know how/if driver can be responsible for such reconnects.
Over all it just TX and RX packets, right? Loosing a signal is
something different, that can be related to the driver's bug. But as
this happens every 5 minutes... I don't know.
Did you try connecting to this AP with any other card and using
similar kernel? I wonder if this can be some supplicant / mac80211
stack issue...
--
Rafał
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Ben Greear @ 2013-06-19 16:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: Linux Wireless List
In-Reply-To: <1371630238.8349.6.camel@jlt4.sipsolutions.net>
On 06/19/2013 01:23 AM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Since my commit 3713b4e364, nl80211_dump_wiphy() uses the global
> nl80211_fam.attrbuf for parsing the incoming data. This wouldn't
> be a problem if it only did so on the first dump iteration which
> is locked against other commands in generic netlink, but due to
> space constraints in cb->args (the needed state doesn't fit) I
> decided to always parse the original message. That's racy though
> since nl80211_fam.attrbuf could be used by some other parsing in
> generic netlink concurrently.
>
> For now, fix this by allocating a separate parse buffer (it's a
> bit too big for the stack, currently 1448 bytes on 64-bit). For
> -next, I'll change the code to parse into the global buffer in
> the first round only and then allocate a smaller buffer to keep
> the state in cb->args.
The commit mentioned above (3713b4e364) is in 3.9.6, but this patch
doesn't come close to applying on my 3.9.6.
Do you happen to know if this should be backported to 3.9 stable or not?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] brcmfmac: Turn off ARP offloading when configured for AP.
From: Greg KH @ 2013-06-19 16:52 UTC (permalink / raw)
To: Arend van Spriel; +Cc: stable, linux-wireless, Hante Meuleman, John W. Linville
In-Reply-To: <51C1D392.8060705@broadcom.com>
On Wed, Jun 19, 2013 at 05:51:46PM +0200, Arend van Spriel wrote:
> On 06/19/2013 04:19 PM, Greg KH wrote:
> >On Wed, Jun 19, 2013 at 09:27:09AM +0200, Arend van Spriel wrote:
> >>On 06/06/2013 10:55 AM, Arend van Spriel wrote:
> >>>From: Hante Meuleman <meuleman@broadcom.com>
> >>
> >>Hi Greg,
> >>
> >>I noticed your review announcement for v3.9.7 and did not see the
> >>change below. I sent it to stable because the original upstream
> >>commit did not apply. Did I miss some step in the process?
> >
> >Ah, somehow I missed your patch, sorry about that, I do have it in my
> >mbox. What kernel tree(s) do you want it to be applied to? I'll pick
> >it up in my next round of releases.
>
> Thanks, Greg
>
> I backported it for the 3.9 tree. It does not apply to 3.8 so I will
> have to create another backport if I need it there.
3.8 is long dead and not maintained by me anymore, but thanks.
Next time you submit stable patches, please let us know somewhere in the
patch/subject what tree it applies to, that makes our lives much easier,
otherwise I just guess and ususally get it wrong :)
thanks,
greg k-h
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Larry Finger @ 2013-06-19 16:35 UTC (permalink / raw)
To: Chris Adams; +Cc: b43-dev, linux-wireless
In-Reply-To: <20130619160911.GB4784@cmadams.net>
On 06/19/2013 11:09 AM, Chris Adams wrote:
> I have a MacBook Pro 8,2 with the BCM4331 wireless chip. I pulled the
> firmware (666.2, 2011-02-23 01:15:07) using b43-fwcutter, and am running
> Fedora 18 (tried up to kernel 3.9.6-200.fc18.x86_64 from updates/testing
> with the same results).
>
> My problem is that it deauthenticates from the AP every 5 minutes (it
> then immediately reconnects). From what I've read, it looks like this
> chip is a little "different"; any ideas/suggestions to help get this
> working better?
>
> Example dmesg chunk:
>
> [ 948.115374] wlan0: associated
> [ 1249.636655] wlan0: deauthenticated from 00:a0:c8:xx:xx:xx (Reason: 1)
My table shows that a "Reason 1" deauthentication is for "unspecified reasons".
Does anyone know why these might occur?
What type of encryption are you using? If it is a re-keying type such as TKIP,
what is the interval? You should find that on the setup page of the access point.
BTW, your mailer is set up strangely. I get your address when I do a plain
Reply, but a Reply All from Thunderbird only got the b43-dev mailing list. I had
to add your address manually.
I also added the linux-wireless ML to the reply as some of my questions are more
likely to be answered there.
Larry
^ permalink raw reply
* pull-request: mac80211 2013-06-19
From: Johannes Berg @ 2013-06-19 16:34 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
Hi John,
One more ...
This is just the fix for the nl80211_fam.attrbuf race Linus ran into and
analysed.
johannes
The following changes since commit 795d855d56c6d172f50a974f603ba923ac93ee76:
mac80211: Fix rate control mask matching call (2013-06-12 09:12:43 +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 3a5a423bb958ad22eeccca66c533e85bf69ba10e:
nl80211: fix attrbuf access race by allocating a separate one (2013-06-19 18:31:20 +0200)
----------------------------------------------------------------
Johannes Berg (1):
nl80211: fix attrbuf access race by allocating a separate one
net/wireless/nl80211.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Linus Torvalds @ 2013-06-19 16:26 UTC (permalink / raw)
To: Johannes Berg
Cc: David Miller, John Linville, Linux Wireless List,
Network Development
In-Reply-To: <1371630238.8349.6.camel@jlt4.sipsolutions.net>
On Tue, Jun 18, 2013 at 10:23 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> Let me know if you want to apply this directly, otherwise I'll send it
> on its way to John.
The problem doesn't happen often enough to make this an acute issue
for me, so this patch might as well go through the normal channels.
Thanks,
Linus
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: hold BSS over association process
From: Ben Greear @ 2013-06-19 16:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1371650017-14293-2-git-send-email-johannes@sipsolutions.net>
On 06/19/2013 06:53 AM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This fixes the potential issue that the BSS struct that we use
> and later assign to wdev->current_bss is removed from the scan
> list while associating.
>
> Also warn when we don't have a BSS struct in connect_result
> unless it's from a driver that only has the connect() API.
This also looks OK to me, but I have not tested it.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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