ath0 timeout problem - again

Sam Leffler sam at
Sat Dec 30 12:51:57 PST 2006

JoaoBR wrote:
> On Thursday 28 December 2006 21:52, you wrote:
>> check this message:
>> run "/usr/src/tools/tools/net80211/wlandebug/wlandebug -i ath0 power" and
>> see if one of the hosts on your wlan has powersaving turned on.
>> "stops forever" was not one of my symptoms though, so your issue may be
>> different...
> thank's for your answer
> powersaving is not the issue here because it's off

See my previous reply to you.  Lamont is directing you to look for
stations in your network operating with power save enabled.

> But I saw histories about this and even if powersaving issue "was the issue in 
> that case(really?)" I think this is wierd in any way because if ONE station 
> with powersaving on could set the AP in DoS ... man ... if really true this 
> is kind of lame excuse or kind of driver weakness which both would be 
> inacceptable, and, if it does NOT wake up if in sleep state ... no further 
> comment, but a driver weakness right?

Power save operation is a required part of 802.11.  If there's a problem
in supporting it then it should be fixed but I'm aware of several ap
products shipping with freebsd that do not exhibit this problem so it
may be related to your configuration.  ath parts offload much processing
to the host and creating a production quality ap based on them involves
certain tuning and configuration that must be done according to the
complete system.

> wether powersaving is on or not on the station/client  is a local setting to 
> this station  and must not influence any remote computer in any way, imagine, 
> you turn on your powersavings and the complete internet goes down on your 
> request hihihihi :)
> but then, like my case, on the AP or better ath in ap mode, even IF 
> powersaving is ON it might stop working for any related reason but firstable 
> NOT WHILE TX/RX and secondable if idle it must return soon THIS computer 
> wants to transmit any kind of traffic again
>  last but not least powersaving might shut the power down but must return when 
> necessary - if not - there is a driver problem.

If you are saying you should not have to reboot a system because the
device locks up then sure.  But I've no idea if that was what was
required.  I'm aware of only one ath-related issue that can lockup a
system--that's when a part is set into deep sleep and the host then
accesses a register outside the pci clock domain w/o first waking up the
part.  This has only been reported with cardbus cards which means you
can just eject the card to unfreeze the bus.  But this sounds unrelated
to the problem you are seeing.


More information about the freebsd-stable mailing list