From owner-freebsd-wireless@FreeBSD.ORG Mon Sep 8 22:14:07 2014 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABA9E14C; Mon, 8 Sep 2014 22:14:07 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A33D14CE; Mon, 8 Sep 2014 22:14:07 +0000 (UTC) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-27.AirBears2.Berkeley.EDU [136.152.142.27]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s88ME58X024714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Sep 2014 15:14:06 -0700 Message-ID: <540E2A2D.4090301@freebsd.org> Date: Mon, 08 Sep 2014 15:14:05 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Issues with urtwn References: <540C751F.6050202@freebsd.org> <540C92D6.4030106@freebsd.org> <540CC53A.90600@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVa/HDnxxIDUvkgMkuLbOIsNG23kc3KbQZhHqi9YQfyghNzuChxHQPSG1ZwHIWLSaRLIcA82Tx1J8xHp884LsQqTdUJo7qPzNeU= X-Sonic-ID: C;CiJdcqU35BGbT0pcoK8kYw== M;dDyccqU35BGbT0pcoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 22:14:07 -0000 So it's definitely to do with powersave. Here's a bunch of iterations of ifconfig list sta on my laptop: ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 149 1 54M 37.0 0 4385 37104 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 149 1 54M 37.5 0 4412 39360 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 149 1 54M 37.5 0 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 149 1 54M 37.5 0 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 149 1 54M 37.5 0 4417 39360 EPS AP HTCAP RSN WME You can see the connection die on the third line, when the txseq and rxseq counters stop incrementing and 'P' gets added to the FLAG field. Does this mean the AP has turned on powersave on its end? -Nathan On 09/07/14 14:07, Adrian Chadd wrote: > Hi, > > The way it's supposed to work in the legacy 802.11 powersave world is > that you send a/any data frame with the powermgt bit in the 802.11 > header set to 0 and the AP goes "oh they're awake!" and sends you your > buffered frames. > > By default powersave isn't enabled, so we should never be _telling_ > the AP that we're going to sleep and the stack always sends data > frames with pwrmgt=0. > > You can ensure it's disabled by ifconfig wlan0 -powersave > > The code in -HEAD that manages that is in ieee80211_power.c. I added > an explicit powersave support mode for NICs that need it done for them > - and the only one it's enabled for right now is ath(4). > > The only reason net80211 sends pwrmgt changes outside of having > net80211 power save enabled is the background scan code. > > I'd compile in IEEE80211_DEBUG in your kernel, then I'd use wlandebug > +scan to see if somehow there's some scanning going on; and wlandebug > +power to see if any power save transitions occur. > > Are you absolutely sure it's a receive side buffering problem, rather > than a send side problem? > > It's also possible that the NIC stops receiving and the AP treats that > as "oh ok, they've gone to sleep for a while." ath(4) now does this in > hostap mode. > > > -a >