[ath9k-devel] ath9k_htc: station unable to authenticate

[ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

Hi,

After a lot of git-bisecting and other testing, it appears that commit
382a103b2b528a3085cde4ac56fc69d92a828b72 (linux-stable.git) is the culprit.

To reproduce the problem, use backports-20130607, and the ath9k defconfig
(with no change otherwise).

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.

After reverting the commit, authentication succeeds very quickly (without the
need to up a monitor vif), just as expected.

Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original
ath9k_htc driver works as expected.  This has been also tested on Debian with
driver from original kernel 3.9 (i.e. without backports).

For the moment I can live with the commit reverted, but I suppose it's been
there to fix something else, so this should probably be looked into by someone
more knowledgeable than me.

Ignacy

-- 
A person is shit's way of making more shit.
		-- S. Barnett, anthropologist.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

So, regression was introduced by this patch:

Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Mar 22 22:30:09 2013 +0100

     mac80211: fix idle handling sequence

     Corey Richardson reported that my idle handling cleanup
     (commit fd0f979a1b, "mac80211: simplify idle handling")
     broke ath9k_htc. The reason appears to be that it wants
     to go out of idle before switching channels. To fix it,
     reimplement that sequence.

     Reported-by: Corey Richardson <corey@octayn.net>
     Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Johannes, can you please take a look on it.



Am 19.06.2013 13:58, schrieb Ignacy Gawedzki:
> Hi,
>
> After a lot of git-bisecting and other testing, it appears that commit
> 382a103b2b528a3085cde4ac56fc69d92a828b72 (linux-stable.git) is the culprit.
>
> To reproduce the problem, use backports-20130607, and the ath9k defconfig
> (with no change otherwise).
>
> 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.
>
> After reverting the commit, authentication succeeds very quickly (without the
> need to up a monitor vif), just as expected.
>
> Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original
> ath9k_htc driver works as expected.  This has been also tested on Debian with
> driver from original kernel 3.9 (i.e. without backports).
>
> For the moment I can live with the commit reverted, but I suppose it's been
> there to fix something else, so this should probably be looked into by someone
> more knowledgeable than me.
>
> Ignacy
>


-- 
Regards,
Oleksij

[ath9k-devel] ath9k_htc: station unable to authenticate

[Berg, Johannes]

 
>      mac80211: fix idle handling sequence
> 
>      Corey Richardson reported that my idle handling cleanup
>      (commit fd0f979a1b, "mac80211: simplify idle handling")
>      broke ath9k_htc. The reason appears to be that it wants
>      to go out of idle before switching channels. To fix it,
>      reimplement that sequence.
> 
>      Reported-by: Corey Richardson <corey@octayn.net>
>      Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> 
> Johannes, can you please take a look on it.

Not very well, I don't know anything about ath9k. I'm willing to help out, but I can't really say what broke it.

johannes

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

RE: [ath9k-devel] ath9k_htc: station unable to authenticate

[Berg, Johannes]

IA0KPiAgICAgIG1hYzgwMjExOiBmaXggaWRsZSBoYW5kbGluZyBzZXF1ZW5jZQ0KPiANCj4gICAg
ICBDb3JleSBSaWNoYXJkc29uIHJlcG9ydGVkIHRoYXQgbXkgaWRsZSBoYW5kbGluZyBjbGVhbnVw
DQo+ICAgICAgKGNvbW1pdCBmZDBmOTc5YTFiLCAibWFjODAyMTE6IHNpbXBsaWZ5IGlkbGUgaGFu
ZGxpbmciKQ0KPiAgICAgIGJyb2tlIGF0aDlrX2h0Yy4gVGhlIHJlYXNvbiBhcHBlYXJzIHRvIGJl
IHRoYXQgaXQgd2FudHMNCj4gICAgICB0byBnbyBvdXQgb2YgaWRsZSBiZWZvcmUgc3dpdGNoaW5n
IGNoYW5uZWxzLiBUbyBmaXggaXQsDQo+ICAgICAgcmVpbXBsZW1lbnQgdGhhdCBzZXF1ZW5jZS4N
Cj4gDQo+ICAgICAgUmVwb3J0ZWQtYnk6IENvcmV5IFJpY2hhcmRzb24gPGNvcmV5QG9jdGF5bi5u
ZXQ+DQo+ICAgICAgU2lnbmVkLW9mZi1ieTogSm9oYW5uZXMgQmVyZyA8am9oYW5uZXMuYmVyZ0Bp
bnRlbC5jb20+DQo+IA0KPiBKb2hhbm5lcywgY2FuIHlvdSBwbGVhc2UgdGFrZSBhIGxvb2sgb24g
aXQuDQoNCk5vdCB2ZXJ5IHdlbGwsIEkgZG9uJ3Qga25vdyBhbnl0aGluZyBhYm91dCBhdGg5ay4g
SSdtIHdpbGxpbmcgdG8gaGVscCBvdXQsIGJ1dCBJIGNhbid0IHJlYWxseSBzYXkgd2hhdCBicm9r
ZSBpdC4NCg0Kam9oYW5uZXMNCg0KSW50ZWwgR21iSApEb3JuYWNoZXIgU3RyYXNzZSAxCjg1NjIy
IEZlbGRraXJjaGVuL011ZW5jaGVuLCBEZXV0c2NobGFuZApTaXR6IGRlciBHZXNlbGxzY2hhZnQ6
IEZlbGRraXJjaGVuIGJlaSBNdWVuY2hlbgpHZXNjaGFlZnRzZnVlaHJlcjogQ2hyaXN0aWFuIExh
bXByZWNodGVyLCBIYW5uZXMgU2Nod2FkZXJlciwgRG91Z2xhcyBMdXNrClJlZ2lzdGVyZ2VyaWNo
dDogTXVlbmNoZW4gSFJCIDQ3NDU2ClVzdC4tSWROci4vVkFUIFJlZ2lzdHJhdGlvbiBOby46IERF
MTI5Mzg1ODk1CkNpdGliYW5rIEZyYW5rZnVydCBhLk0uIChCTFogNTAyIDEwOSAwMCkgNjAwMTE5
MDUyCg==

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

Am 19.06.2013 15:08, schrieb Berg, Johannes:
>
>>       mac80211: fix idle handling sequence
>>
>>       Corey Richardson reported that my idle handling cleanup
>>       (commit fd0f979a1b, "mac80211: simplify idle handling")
>>       broke ath9k_htc. The reason appears to be that it wants
>>       to go out of idle before switching channels. To fix it,
>>       reimplement that sequence.
>>
>>       Reported-by: Corey Richardson <corey@octayn.net>
>>       Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>>
>> Johannes, can you please take a look on it.
>
> Not very well, I don't know anything about ath9k. I'm willing to help out, but I can't really say what broke it.

hm.. looks like this code depends on power_save. is it correct?

Ignacy,

can you please take a look if power_save mode is enabled by you.

iw dev wlan0 get power_save

if yes. Try to disable it.

I think last week power_save was set to disabled by default. There are 
too many bugs right now.
-- 
Regards,
Oleksij

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

Am 19.06.2013 15:08, schrieb Berg, Johannes:
>
>>       mac80211: fix idle handling sequence
>>
>>       Corey Richardson reported that my idle handling cleanup
>>       (commit fd0f979a1b, "mac80211: simplify idle handling")
>>       broke ath9k_htc. The reason appears to be that it wants
>>       to go out of idle before switching channels. To fix it,
>>       reimplement that sequence.
>>
>>       Reported-by: Corey Richardson <corey@octayn.net>
>>       Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>>
>> Johannes, can you please take a look on it.
>
> Not very well, I don't know anything about ath9k. I'm willing to help out, but I can't really say what broke it.

hm.. looks like this code depends on power_save. is it correct?

Ignacy,

can you please take a look if power_save mode is enabled by you.

iw dev wlan0 get power_save

if yes. Try to disable it.

I think last week power_save was set to disabled by default. There are 
too many bugs right now.
-- 
Regards,
Oleksij

[ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

On Wed, Jun 19, 2013 at 03:38:47PM +0200, thus spake Oleksij Rempel:
> hm.. looks like this code depends on power_save. is it correct?
> 
> Ignacy,
> 
> can you please take a look if power_save mode is enabled by you.
> 
> iw dev wlan0 get power_save
> 
> if yes. Try to disable it.

Although I have been building with CFG80211_DEFAULT_PS=y, the iw get
power_save command tells me it's off.

> I think last week power_save was set to disabled by default. There
> are too many bugs right now.

I'll test without CFG80211_DEFAULT_PS, just to be sure.

Thanks for the hint.

-- 
NO CARRIER

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

On Wed, Jun 19, 2013 at 03:38:47PM +0200, thus spake Oleksij Rempel:
> hm.. looks like this code depends on power_save. is it correct?
> 
> Ignacy,
> 
> can you please take a look if power_save mode is enabled by you.
> 
> iw dev wlan0 get power_save
> 
> if yes. Try to disable it.

Although I have been building with CFG80211_DEFAULT_PS=y, the iw get
power_save command tells me it's off.

> I think last week power_save was set to disabled by default. There
> are too many bugs right now.

I'll test without CFG80211_DEFAULT_PS, just to be sure.

Thanks for the hint.

-- 
NO CARRIER

[ath9k-devel] ath9k_htc: station unable to authenticate

[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

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[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

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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.


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?

-- 
Regards,
Oleksij

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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.


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?

-- 
Regards,
Oleksij

[ath9k-devel] ath9k_htc: station unable to authenticate

[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?

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[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?

[ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

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.

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

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.

[ath9k-devel] ath9k_htc: station unable to authenticate

[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.

-- 
Everything is more fun naked except cooking with grease.

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[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.

-- 
Everything is more fun naked except cooking with grease.

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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

[ath9k-devel] ath9k_htc: station unable to authenticate

[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...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[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...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] ath9k_htc: station unable to authenticate

[Corey Richardson]

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 :(

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Corey Richardson]

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 :(

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

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

[ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

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. 

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

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. 

[ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

On Wed, Jun 19, 2013 at 11:39:55AM -0700, thus spake Ben Greear:
> Does the ath9k_htc do it's own rate control, perhaps modelled on
> ath9k_rate_control algorithm?

Do you mean ATH9K_LEGACY_RATE_CONTROL ?

> If so, that could be the problem...it has issues with associating when
> network conditions are poor...

Frankly, I doubt this is the case.  With so many different setups, and the AP
is like one meter away from the station right now.

-- 
The groove will take you through times without money
much better than money will take you through times without groove.

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

On Wed, Jun 19, 2013 at 11:39:55AM -0700, thus spake Ben Greear:
> Does the ath9k_htc do it's own rate control, perhaps modelled on
> ath9k_rate_control algorithm?

Do you mean ATH9K_LEGACY_RATE_CONTROL ?

> If so, that could be the problem...it has issues with associating when
> network conditions are poor...

Frankly, I doubt this is the case.  With so many different setups, and the AP
is like one meter away from the station right now.

-- 
The groove will take you through times without money
much better than money will take you through times without groove.

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

Am 19.06.2013 21:33, schrieb Ignacy Gawedzki:
> 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.

this one is BG with Broadcom BCM4318. Is here original firmware or openwrt?

>    - Netgear DG834Gv5 (don't know which firmware and can't check at this time).

this is BG with Conexant CX94610

>    - hostapd (can't say which version at this time either) with the same
>      ath9k_htc.

this one is actually BGN, did you configured it for N? Can you please 
provide your hostapd.conf.

Do you have problems on all 3 configurations? Can you please test it 
with some N (HT) capable AP. But please, not with N-draft certified AP.

-- 
Regards,
Oleksij

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

Am 19.06.2013 21:33, schrieb Ignacy Gawedzki:
> 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.

this one is BG with Broadcom BCM4318. Is here original firmware or openwrt?

>    - Netgear DG834Gv5 (don't know which firmware and can't check at this time).

this is BG with Conexant CX94610

>    - hostapd (can't say which version at this time either) with the same
>      ath9k_htc.

this one is actually BGN, did you configured it for N? Can you please 
provide your hostapd.conf.

Do you have problems on all 3 configurations? Can you please test it 
with some N (HT) capable AP. But please, not with N-draft certified AP.

-- 
Regards,
Oleksij

[ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

On Thu, Jun 20, 2013 at 07:33:30AM +0200, thus spake Oleksij Rempel:
> Am 19.06.2013 21:33, schrieb Ignacy Gawedzki:
> >I tested the thing with at least three different APs:
> >
> >   - Netgear DG834Gv4 with latest firmware.
> 
> this one is BG with Broadcom BCM4318. Is here original firmware or openwrt?

Original firmware, since OpenWRT doesn't support the ADSL chip.

> >   - Netgear DG834Gv5 (don't know which firmware and can't check at this time).
> 
> this is BG with Conexant CX94610
> 
> >   - hostapd (can't say which version at this time either) with the same
> >     ath9k_htc.
> 
> this one is actually BGN, did you configured it for N? Can you
> please provide your hostapd.conf.

I'll manage to get the configuration as soon as possible.  It seems the
association problem went away since I patched the drivers on the AP too, so
"unpatching" the drivers on the station is not enough to reproduce the
problem.  I'll unpatch the drivers on the AP and re-run the test.

> Do you have problems on all 3 configurations?

On both Netgears for sure.  For hostapd I'll confirm that in a little while.

>                                               Can you please test it
> with some N (HT) capable AP. But please, not with N-draft certified
> AP.

Is ath9k_htc N-capable?

-- 
I used to have a sig, but I've stopped smoking now.

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

On Thu, Jun 20, 2013 at 07:33:30AM +0200, thus spake Oleksij Rempel:
> Am 19.06.2013 21:33, schrieb Ignacy Gawedzki:
> >I tested the thing with at least three different APs:
> >
> >   - Netgear DG834Gv4 with latest firmware.
> 
> this one is BG with Broadcom BCM4318. Is here original firmware or openwrt?

Original firmware, since OpenWRT doesn't support the ADSL chip.

> >   - Netgear DG834Gv5 (don't know which firmware and can't check at this time).
> 
> this is BG with Conexant CX94610
> 
> >   - hostapd (can't say which version at this time either) with the same
> >     ath9k_htc.
> 
> this one is actually BGN, did you configured it for N? Can you
> please provide your hostapd.conf.

I'll manage to get the configuration as soon as possible.  It seems the
association problem went away since I patched the drivers on the AP too, so
"unpatching" the drivers on the station is not enough to reproduce the
problem.  I'll unpatch the drivers on the AP and re-run the test.

> Do you have problems on all 3 configurations?

On both Netgears for sure.  For hostapd I'll confirm that in a little while.

>                                               Can you please test it
> with some N (HT) capable AP. But please, not with N-draft certified
> AP.

Is ath9k_htc N-capable?

-- 
I used to have a sig, but I've stopped smoking now.

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

Am 20.06.2013 08:39, schrieb Ignacy Gawedzki:
> On Thu, Jun 20, 2013 at 07:33:30AM +0200, thus spake Oleksij Rempel:
>> Am 19.06.2013 21:33, schrieb Ignacy Gawedzki:
>>> I tested the thing with at least three different APs:
>>>
>>>    - Netgear DG834Gv4 with latest firmware.
>>
>> this one is BG with Broadcom BCM4318. Is here original firmware or openwrt?
>
> Original firmware, since OpenWRT doesn't support the ADSL chip.
>
>>>    - Netgear DG834Gv5 (don't know which firmware and can't check at this time).
>>
>> this is BG with Conexant CX94610
>>
>>>    - hostapd (can't say which version at this time either) with the same
>>>      ath9k_htc.
>>
>> this one is actually BGN, did you configured it for N? Can you
>> please provide your hostapd.conf.
>
> I'll manage to get the configuration as soon as possible.  It seems the
> association problem went away since I patched the drivers on the AP too, so
> "unpatching" the drivers on the station is not enough to reproduce the
> problem.  I'll unpatch the drivers on the AP and re-run the test.
>
>> Do you have problems on all 3 configurations?
>
> On both Netgears for sure.  For hostapd I'll confirm that in a little while.
>
>>                                                Can you please test it
>> with some N (HT) capable AP. But please, not with N-draft certified
>> AP.
>
> Is ath9k_htc N-capable?

Yes, if hostapd configured properly.

Question to Corey,

i assume your old AP was supporting only BG networks. And your new one, 
which is working fine, supports N?

-- 
Regards,
Oleksij

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

Am 20.06.2013 08:39, schrieb Ignacy Gawedzki:
> On Thu, Jun 20, 2013 at 07:33:30AM +0200, thus spake Oleksij Rempel:
>> Am 19.06.2013 21:33, schrieb Ignacy Gawedzki:
>>> I tested the thing with at least three different APs:
>>>
>>>    - Netgear DG834Gv4 with latest firmware.
>>
>> this one is BG with Broadcom BCM4318. Is here original firmware or openwrt?
>
> Original firmware, since OpenWRT doesn't support the ADSL chip.
>
>>>    - Netgear DG834Gv5 (don't know which firmware and can't check at this time).
>>
>> this is BG with Conexant CX94610
>>
>>>    - hostapd (can't say which version at this time either) with the same
>>>      ath9k_htc.
>>
>> this one is actually BGN, did you configured it for N? Can you
>> please provide your hostapd.conf.
>
> I'll manage to get the configuration as soon as possible.  It seems the
> association problem went away since I patched the drivers on the AP too, so
> "unpatching" the drivers on the station is not enough to reproduce the
> problem.  I'll unpatch the drivers on the AP and re-run the test.
>
>> Do you have problems on all 3 configurations?
>
> On both Netgears for sure.  For hostapd I'll confirm that in a little while.
>
>>                                                Can you please test it
>> with some N (HT) capable AP. But please, not with N-draft certified
>> AP.
>
> Is ath9k_htc N-capable?

Yes, if hostapd configured properly.

Question to Corey,

i assume your old AP was supporting only BG networks. And your new one, 
which is working fine, supports N?

-- 
Regards,
Oleksij

[ath9k-devel] ath9k_htc: station unable to authenticate

[Sujith Manoharan]

Ignacy Gawedzki wrote:
> After reverting the commit, authentication succeeds very quickly (without the
> need to up a monitor vif), just as expected.
> 
> Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original
> ath9k_htc driver works as expected.  This has been also tested on Debian with
> driver from original kernel 3.9 (i.e. without backports).
> 
> For the moment I can live with the commit reverted, but I suppose it's been
> there to fix something else, so this should probably be looked into by someone
> more knowledgeable than me.

Can you test if this patch helps (without reverting the mac80211 commit) ?

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index eaa94fe..fba6ea7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1183,7 +1183,7 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
 		mutex_lock(&priv->htc_pm_lock);
 
 		priv->ps_idle = !!(conf->flags & IEEE80211_CONF_IDLE);
-		if (priv->ps_idle)
+		if (!priv->ps_idle)
 			chip_reset = true;
 
 		mutex_unlock(&priv->htc_pm_lock);


Sujith

[ath9k-devel] ath9k_htc: station unable to authenticate

[Ignacy Gawedzki]

On Thu, Jun 20, 2013 at 12:39:29PM +0530, thus spake Sujith Manoharan:
> Ignacy Gawedzki wrote:
> > After reverting the commit, authentication succeeds very quickly (without the
> > need to up a monitor vif), just as expected.
> > 
> > Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original
> > ath9k_htc driver works as expected.  This has been also tested on Debian with
> > driver from original kernel 3.9 (i.e. without backports).
> > 
> > For the moment I can live with the commit reverted, but I suppose it's been
> > there to fix something else, so this should probably be looked into by someone
> > more knowledgeable than me.
> 
> Can you test if this patch helps (without reverting the mac80211 commit) ?

It works indeed, at least with the DG834Gv4.

> 
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> index eaa94fe..fba6ea7 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> @@ -1183,7 +1183,7 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
>  		mutex_lock(&priv->htc_pm_lock);
>  
>  		priv->ps_idle = !!(conf->flags & IEEE80211_CONF_IDLE);
> -		if (priv->ps_idle)
> +		if (!priv->ps_idle)
>  			chip_reset = true;
>  
>  		mutex_unlock(&priv->htc_pm_lock);
> 
> 
> Sujith
> 

-- 
 "The whole problem with the world is that fools and fanatics are
   always so certain of themselves, and wiser people so full of doubts."
                                                 - Bertrand Russell

[ath9k-devel] ath9k_htc: station unable to authenticate

[Sujith Manoharan]

Ignacy Gawedzki wrote:
> > Can you test if this patch helps (without reverting the mac80211 commit) ?
> 
> It works indeed, at least with the DG834Gv4.

Thanks for testing. I've posted the patch:
https://patchwork.kernel.org/patch/2753741/

Sujith

[ath9k-devel] ath9k_htc: station unable to authenticate

[Oleksij Rempel]

Am 20.06.2013 10:28, schrieb Sujith Manoharan:
> Ignacy Gawedzki wrote:
>>> Can you test if this patch helps (without reverting the mac80211 commit) ?
>>
>> It works indeed, at least with the DG834Gv4.

cool

> Thanks for testing. I've posted the patch:
> https://patchwork.kernel.org/patch/2753741/

here i need some help. Why it was not always reproducible? It depends on 
timing, protocol, moon position?


-- 
Regards,
Oleksij

[ath9k-devel] ath9k_htc: station unable to authenticate

[Sujith Manoharan]

Oleksij Rempel wrote:
> here i need some help. Why it was not always reproducible? It depends on 
> timing, protocol, moon position?

The bug was consistently reproducible at my end.

Sujith

[ath9k-devel] ath9k_htc: station unable to authenticate

[Corey Richardson]

On Thu, Jun 20, 2013 at 2:47 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Question to Corey,
>
> i assume your old AP was supporting only BG networks. And your new one,
> which is working fine, supports N?
>

Yes, this is true. It was also using TKIP encryption, if that is relevant.

Re: [ath9k-devel] ath9k_htc: station unable to authenticate

[Corey Richardson]

On Thu, Jun 20, 2013 at 2:47 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Question to Corey,
>
> i assume your old AP was supporting only BG networks. And your new one,
> which is working fine, supports N?
>

Yes, this is true. It was also using TKIP encryption, if that is relevant.