Date: Thu, 18 May 2006 09:35:28 +0200 From: Sam Leffler <sam@errno.com> To: Ross Finlayson <finlayson@live555.com> Cc: freebsd-mobile@freebsd.org Subject: Re: More 'resource' problems with "ath0" Message-ID: <446C23C0.8030501@errno.com> In-Reply-To: <7.0.1.0.1.20060517230855.01ddd570@live555.com> References: <7.0.1.0.1.20060517080119.01e00df8@live555.com> <446B44B0.5030908@errno.com> <7.0.1.0.1.20060517125415.01e0f568@live555.com> <446B8F14.80502@errno.com> <7.0.1.0.1.20060517153640.01e0f568@live555.com> <446C0C22.4090700@errno.com> <7.0.1.0.1.20060517230855.01ddd570@live555.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ross Finlayson wrote: > >> > 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 :-) Power save support is required by any ap that follows the standard and there is no way to disable it (at the moment). > >> 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. Same thing if I recall (this is from memory). > >> 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... So your clients are operating in ps mode and this may be the same issue seen by one other person. I'm working on it but am traveling right now so nothing will happen for a while (and it's also hard to reproduce). Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?446C23C0.8030501>