More 'resource' problems with "ath0"

[Ross Finlayson]

> > No, I don't use power save mode.  (One of the servers is at home, where
> > all of its clients are plugged in to AC power.  The other server is at a
> > local coffee shop, where the owner wants to discourage people from
> > camping there for hours :-)
>
>Er, we're talking about wireless operation here

So was I :-)

>If the stations associated to the ap are operating in power save mode

If the *access point* is not explicitly configured to use power save 
mode - which it's not - then will the clients still get power save 
mode if they ask for it?  I thought that the access point made the 
final decision as to whether power save mode was used?  But maybe I'm 
wrong about that :-)

>buffer frames for the client.  I'm aware of one outstanding issue with
>this mode whereby frames (apparently) can be stuck on the buffering q
>because the beacon frame stops being transmitted.  This problem is
>currently unresolved (however you would also see messages on the ap
>about "transmit timeout").

I have never seen any "transmit timeout" messages, but several "ath0: 
device timeout" messages.

>I don't recall if stations associated with power save are marked in the
>display shown by
>
>ifconfig ath0 list sta

I don't think so:

%ifconfig ath0 list sta
ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS ERP
00:14:51:ef:b9:72    1    3   5M   17  120  33078  12512 ES     0
00:12:f0:ba:59:f2    2    3   1M   18  120  22933  63680 ES     0

The second client (00:12:f0:ba:59:f2) requests power save mode - but 
I see no indication of that.

>If not then turning on power debug msgs at the 802.11 layer with
>wlandebug; e.g.
>
>wlandebug -i ath0 power

When I do this, I get:

ath0: [00:12:f0:ba:59:f2] save frame with age 3, 1 now queued
ath0: [00:12:f0:ba:59:f2] power save mode off, 0 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] flush ps queue, 1 packets queued
ath0: [00:12:f0:ba:59:f2] power save mode on, 1 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] save frame with age 3, 1 now queued
ath0: ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1
ath0: [00:12:f0:ba:59:f2] power save mode off, 0 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] flush ps queue, 1 packets queued
ath0: ieee80211_beacon_update: TIM updated, pending 0, off 0, len 1
ath0: [00:12:f0:ba:59:f2] power save mode on, 1 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode off, 0 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode on, 1 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode off, 0 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode on, 1 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode off, 0 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode on, 1 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode off, 0 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode on, 1 sta's in ps mode
ath0: [00:12:f0:ba:59:f2] power save mode off, 0 sta's in ps mode

(with the last two lines being repeated indefinitely)


>will definitely show whether any are present (use wlandebug -i ath0 0
>after to reset).
>
> >
> >>  Is there some reason you have the cards locked to 11b?  If
> >> not, you should be able to let them operate in 11g.
> >
> > In each case, the back-end Internet connection is only 1.5 Mbps, so the
> > extra bitrate of 11g was not needed.  However, on your suggestion, I'll
> > try running both servers at 11g now.
>
>It should not matter but 11g is the typical usage and if clients are
>confused by being forced to operate in 11b the problem may go away.

So far I have not seen the problem recur after I switched to using 
11g.  So I'm keeping my fingers crossed...

         Ross.