This may be related to this other thread
http://marc.info/?l=linux-wireless&m=122187323506092&w=2
With the 2.6.27-rc6 kernel I find that my wireless connection dies after a few
minutes. Using nm-applet I have to disable wireless and re-enable it before I
can re-establish a session (using WPA).
I tried pulling the wireless-testing branch and found it behaved strangely as
well - within about 30 seconds of idle time it would die. But, it would
usually immediately begin to reconnect (and succeed). My logs were full of
"ForceXPAon: 0" messages which I found were from ath9_hw_reset(), which were
all being called from set_channel, during the scan that took place when the
card was not associated with the AP. It typically occurred every 30-35 seconds.
I also found that if I kept a ping session to my wifi router running, then the
wireless connection would not die, it would operate normally.
It seems that it all worked fine in 2.6.27-rc4...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Luis R. Rodriguez wrote:
> On Mon, Sep 22, 2008 at 04:31:33AM -0700, Howard Chu wrote:
>> Luis R. Rodriguez wrote:
>>> On Mon, Sep 22, 2008 at 2:09 AM, Howard Chu<[email protected]> wrote:
>>>>> For example - I added DPRINTFs to all the places that called ath9_hw_reset()
>>>>> to see why the ForceXPAon message was occurring so often, and got the
>>>>> attached log. I note that ForceXPAon doesn't occur on every call to
>>>>> hw_reset, and sometimes there are repeated identical calls to set the
>>>>> channel (e.g. at 22:06:36 in the log).
>>>>>
>>>>> It associates successfully with my AP on channel 8, but shortly thereafter
>>>>> loses the association, scans again, and starts over again, ad nauseam. This
>>>>> behavior was made even worse when I upgraded my freeradius server (was
>>>>> authenticating with WPA EAP/PEAP) and configured TLS session caching - there
>>>>> seems to be a bug in freeradius there so subsequent reassociation attempts
>>>>> would always fail until I turned off session caching. (Haven't had time to
>>>>> chase that down yet.)
>>> Howard, did you apply the pending group key patch yet?
>> Yes, the patch didn't improve the situation on my wireless-testing build. It
>> works fine on my 2.6.27-rc6 build though.
>
> Can you provide a long of your wireless-testing run with the group key
> patch applied?
The log I posted already had the group key patch applied. I have an earlier
log (Sep 18) from before patching, but it doesn't look much different. Do you
want me to post that?
> Also, please try running wpa_supplicant manually, but
> first be sure to disable Network Manager completely by doing:
Will try that shortly.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Luis R. Rodriguez wrote:
> On Mon, Sep 22, 2008 at 2:09 AM, Howard Chu<[email protected]> wrote:
>> > For example - I added DPRINTFs to all the places that called ath9_hw_reset()
>> > to see why the ForceXPAon message was occurring so often, and got the
>> > attached log. I note that ForceXPAon doesn't occur on every call to
>> > hw_reset, and sometimes there are repeated identical calls to set the
>> > channel (e.g. at 22:06:36 in the log).
>> >
>> > It associates successfully with my AP on channel 8, but shortly thereafter
>> > loses the association, scans again, and starts over again, ad nauseam. This
>> > behavior was made even worse when I upgraded my freeradius server (was
>> > authenticating with WPA EAP/PEAP) and configured TLS session caching - there
>> > seems to be a bug in freeradius there so subsequent reassociation attempts
>> > would always fail until I turned off session caching. (Haven't had time to
>> > chase that down yet.)
>
> Howard, did you apply the pending group key patch yet?
Yes, the patch didn't improve the situation on my wireless-testing build. It
works fine on my 2.6.27-rc6 build though.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On Sat, Sep 20, 2008 at 09:22:56PM -0700, Steven Noonan wrote:
> On Sat, Sep 20, 2008 at 9:17 PM, Howard Chu <[email protected]> wrote:
> > With the 2.6.27-rc6 kernel I find that my wireless connection dies after a
> > few minutes. Using nm-applet I have to disable wireless and re-enable it
> > before I can re-establish a session (using WPA).
>
> Yeah, you need this patch:
> http://marc.info/?l=linux-wireless&m=122163541519736&w=2
>
> > I tried pulling the wireless-testing branch and found it behaved strangely
> > as well - within about 30 seconds of idle time it would die. But, it would
> > usually immediately begin to reconnect (and succeed). My logs were full of
> > "ForceXPAon: 0" messages which I found were from ath9_hw_reset(), which were
> > all being called from set_channel, during the scan that took place when the
> > card was not associated with the AP. It typically occurred every 30-35
> > seconds.
>
> I'm sure the ath9k guys can be more informative about what
> 'ForceXPAon: 0' is all about,
Its set *all the time* for our newer chipsets and can be safely ignored.
Not sure what the register is exactly for but its always set on
our newer chipsets upon reset.
> but wireless-testing is pretty outdated
This is not accurate.
It lacks new patches from Linus' tree, but it has the latest
and greatest possible wireless patches. John maintains Linux
wireless so he'll always have more updated patches for wireless than
Linus.
Luis
On Mon, Sep 22, 2008 at 04:31:33AM -0700, Howard Chu wrote:
> Luis R. Rodriguez wrote:
> > On Mon, Sep 22, 2008 at 2:09 AM, Howard Chu<[email protected]> wrote:
> >> > For example - I added DPRINTFs to all the places that called ath9_hw_reset()
> >> > to see why the ForceXPAon message was occurring so often, and got the
> >> > attached log. I note that ForceXPAon doesn't occur on every call to
> >> > hw_reset, and sometimes there are repeated identical calls to set the
> >> > channel (e.g. at 22:06:36 in the log).
> >> >
> >> > It associates successfully with my AP on channel 8, but shortly thereafter
> >> > loses the association, scans again, and starts over again, ad nauseam. This
> >> > behavior was made even worse when I upgraded my freeradius server (was
> >> > authenticating with WPA EAP/PEAP) and configured TLS session caching - there
> >> > seems to be a bug in freeradius there so subsequent reassociation attempts
> >> > would always fail until I turned off session caching. (Haven't had time to
> >> > chase that down yet.)
> >
> > Howard, did you apply the pending group key patch yet?
>
> Yes, the patch didn't improve the situation on my wireless-testing build. It
> works fine on my 2.6.27-rc6 build though.
Can you provide a long of your wireless-testing run with the group key
patch applied? Also, please try running wpa_supplicant manually, but
first be sure to disable Network Manager completely by doing:
# Red Hat based systems
sudo /sbin/service NetworkMananger stop
# Debian based systems (Ubuntu is one)
sudo /etc/init.d/NetworkManager stop
sudo killall -TERM wpa_supplicant
Please read:
http://wireless.kernel.org/en/users/Reporting_bugs
Luis
On Mon, Sep 22, 2008 at 12:21:52AM -0700, Steven Noonan wrote:
> On Sun, Sep 21, 2008 at 11:48 PM, Luis R. Rodriguez
> <[email protected]> wrote:
> >> but wireless-testing is pretty outdated
> >
> > This is not accurate.
> >
> > It lacks new patches from Linus' tree, but it has the latest
> > and greatest possible wireless patches. John maintains Linux
> > wireless so he'll always have more updated patches for wireless than
> > Linus.
> >
>
> I've had much less luck running wireless-testing than I have had
> running -tip or Linus' trees. Perhaps it -is- inaccurate that it's
> outdated, but it's certainly less usable, from what I've seen.
Its a development branch, it should be usable but people using
it are also expected to provide constructive criticism and at the
very best patches.
Luis
Luis R. Rodriguez wrote:
> On Sat, Sep 20, 2008 at 09:22:56PM -0700, Steven Noonan wrote:
>> On Sat, Sep 20, 2008 at 9:17 PM, Howard Chu<[email protected]> wrote:
>>> I tried pulling the wireless-testing branch and found it behaved strangely
>>> as well - within about 30 seconds of idle time it would die. But, it would
>>> usually immediately begin to reconnect (and succeed). My logs were full of
>>> "ForceXPAon: 0" messages which I found were from ath9_hw_reset(), which were
>>> all being called from set_channel, during the scan that took place when the
>>> card was not associated with the AP. It typically occurred every 30-35
>>> seconds.
>> I'm sure the ath9k guys can be more informative about what
>> 'ForceXPAon: 0' is all about,
>
> Its set *all the time* for our newer chipsets and can be safely ignored.
> Not sure what the register is exactly for but its always set on
> our newer chipsets upon reset.
Yes, I understood that. But the fact that it was being logged repeatedly even
after a session was connected, whereas before it always stopped once an
association was made, was suspicious. And in fact I now see that it gets
logged repeatedly because the association is repeatedly lost and re-established.
For example - I added DPRINTFs to all the places that called ath9_hw_reset()
to see why the ForceXPAon message was occurring so often, and got the attached
log. I note that ForceXPAon doesn't occur on every call to hw_reset, and
sometimes there are repeated identical calls to set the channel (e.g. at
22:06:36 in the log).
It associates successfully with my AP on channel 8, but shortly thereafter
loses the association, scans again, and starts over again, ad nauseam. This
behavior was made even worse when I upgraded my freeradius server (was
authenticating with WPA EAP/PEAP) and configured TLS session caching - there
seems to be a bug in freeradius there so subsequent reassociation attempts
would always fail until I turned off session caching. (Haven't had time to
chase that down yet.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On Sun, Sep 21, 2008 at 11:48 PM, Luis R. Rodriguez
<[email protected]> wrote:
>> but wireless-testing is pretty outdated
>
> This is not accurate.
>
> It lacks new patches from Linus' tree, but it has the latest
> and greatest possible wireless patches. John maintains Linux
> wireless so he'll always have more updated patches for wireless than
> Linus.
>
I've had much less luck running wireless-testing than I have had
running -tip or Linus' trees. Perhaps it -is- inaccurate that it's
outdated, but it's certainly less usable, from what I've seen.
- Steven
2008/9/21 Steven Noonan <[email protected]>:
> I'm sure the ath9k guys can be more informative about what
> 'ForceXPAon: 0' is all about, but wireless-testing is pretty outdated
> now. Strange, too, because it seems that even Linus' tree has newer
> code than wireless-testing.
>
I guess it stands for eXternal Pre Amplifier, so ForceXPAon -> Force
external pre amplifier on...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Sat, Sep 20, 2008 at 9:17 PM, Howard Chu <[email protected]> wrote:
> With the 2.6.27-rc6 kernel I find that my wireless connection dies after a
> few minutes. Using nm-applet I have to disable wireless and re-enable it
> before I can re-establish a session (using WPA).
Yeah, you need this patch:
http://marc.info/?l=linux-wireless&m=122163541519736&w=2
> I tried pulling the wireless-testing branch and found it behaved strangely
> as well - within about 30 seconds of idle time it would die. But, it would
> usually immediately begin to reconnect (and succeed). My logs were full of
> "ForceXPAon: 0" messages which I found were from ath9_hw_reset(), which were
> all being called from set_channel, during the scan that took place when the
> card was not associated with the AP. It typically occurred every 30-35
> seconds.
I'm sure the ath9k guys can be more informative about what
'ForceXPAon: 0' is all about, but wireless-testing is pretty outdated
now. Strange, too, because it seems that even Linus' tree has newer
code than wireless-testing.
> I also found that if I kept a ping session to my wifi router running, then
> the wireless connection would not die, it would operate normally.
>
> It seems that it all worked fine in 2.6.27-rc4...
Yeah, did a git-bisect on the issue. Again, see the above link to get
the patch for it. :)
- Steven
On Mon, Sep 22, 2008 at 2:09 AM, Howard Chu <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>>
>> On Sat, Sep 20, 2008 at 09:22:56PM -0700, Steven Noonan wrote:
>>>
>>> On Sat, Sep 20, 2008 at 9:17 PM, Howard Chu<[email protected]> wrote:
>
>>>> I tried pulling the wireless-testing branch and found it behaved
>>>> strangely
>>>> as well - within about 30 seconds of idle time it would die. But, it
>>>> would
>>>> usually immediately begin to reconnect (and succeed). My logs were full
>>>> of
>>>> "ForceXPAon: 0" messages which I found were from ath9_hw_reset(), which
>>>> were
>>>> all being called from set_channel, during the scan that took place when
>>>> the
>>>> card was not associated with the AP. It typically occurred every 30-35
>>>> seconds.
>>>
>>> I'm sure the ath9k guys can be more informative about what
>>> 'ForceXPAon: 0' is all about,
>>
>> Its set *all the time* for our newer chipsets and can be safely ignored.
>> Not sure what the register is exactly for but its always set on
>> our newer chipsets upon reset.
>
> Yes, I understood that. But the fact that it was being logged repeatedly
> even after a session was connected, whereas before it always stopped once an
> association was made, was suspicious. And in fact I now see that it gets
> logged repeatedly because the association is repeatedly lost and
> re-established.
>
> For example - I added DPRINTFs to all the places that called ath9_hw_reset()
> to see why the ForceXPAon message was occurring so often, and got the
> attached log. I note that ForceXPAon doesn't occur on every call to
> hw_reset, and sometimes there are repeated identical calls to set the
> channel (e.g. at 22:06:36 in the log).
>
> It associates successfully with my AP on channel 8, but shortly thereafter
> loses the association, scans again, and starts over again, ad nauseam. This
> behavior was made even worse when I upgraded my freeradius server (was
> authenticating with WPA EAP/PEAP) and configured TLS session caching - there
> seems to be a bug in freeradius there so subsequent reassociation attempts
> would always fail until I turned off session caching. (Haven't had time to
> chase that down yet.)
Howard, did you apply the pending group key patch yet?
Luis
On Mon, Sep 22, 2008 at 12:21:52AM -0700, Steven Noonan wrote:
> On Sun, Sep 21, 2008 at 11:48 PM, Luis R. Rodriguez
> <[email protected]> wrote:
> >> but wireless-testing is pretty outdated
> >
> > This is not accurate.
> >
> > It lacks new patches from Linus' tree, but it has the latest
> > and greatest possible wireless patches. John maintains Linux
> > wireless so he'll always have more updated patches for wireless than
> > Linus.
> >
>
> I've had much less luck running wireless-testing than I have had
> running -tip or Linus' trees. Perhaps it -is- inaccurate that it's
> outdated, but it's certainly less usable, from what I've seen.
The wireless-testing tree is based on an -rc from Linus plus any later
wireless patches (minus whatever is still sitting in my mailbox at
the time). If it is less usable, it is either due to some wireless
breakage (send us bug reports) or Linus is producing crap -rc releases
(possible).
Current wireless-testing is based on 2.6.27-rc6. Since -rc7 just
came-out yesterday...
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.