From owner-freebsd-mobile@FreeBSD.ORG Thu May 18 06:27:20 2006 Return-Path: X-Original-To: freebsd-mobile@freebsd.org Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6977716A400 for ; Thu, 18 May 2006 06:27:20 +0000 (UTC) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (ns.live555.com [66.80.62.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4CAD43D46 for ; Thu, 18 May 2006 06:27:19 +0000 (GMT) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.13.6/8.13.6) with ESMTP id k4I6RIIZ013591 for ; Wed, 17 May 2006 23:27:18 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.13.6/8.13.6/Submit) id k4I6RITO013584; Wed, 17 May 2006 23:27:18 -0700 (PDT) (envelope-from rsf) Message-Id: <7.0.1.0.1.20060517230855.01ddd570@live555.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 17 May 2006 23:27:09 -0700 To: freebsd-mobile@freebsd.org From: Ross Finlayson In-Reply-To: <446C0C22.4090700@errno.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: More 'resource' problems with "ath0" X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 06:27:20 -0000 > > 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.