From owner-freebsd-wireless@FreeBSD.ORG Sun Sep 7 17:16:14 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 DB41D331; Sun, 7 Sep 2014 17:16:14 +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 A6FB0116D; Sun, 7 Sep 2014 17:16:14 +0000 (UTC) Received: from zeppelin.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s87HG6Cj030525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 7 Sep 2014 10:16:07 -0700 Message-ID: <540C92D6.4030106@freebsd.org> Date: Sun, 07 Sep 2014 10:16:06 -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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbof3XfFEh4wib9jDHJ4lHrScKgtqJXM07PddgtDXtJoEXBTn8nRVL8qceWfcE159BNLjsgKp5oxQcvEqerJxqpmDkAxcAYIDk= X-Sonic-ID: C;wjxEp7I25BGsREpcoK8kYw== M;Usyrp7I25BGsREpcoK8kYw== 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: Sun, 07 Sep 2014 17:16:14 -0000 On 09/07/14 08:28, Adrian Chadd wrote: > On 7 September 2014 08:09, Nathan Whitehorn wrote: >> I've been having some issues with connection stability in urtwn for several >> months. The usual symptom is that after some period of time the connection >> will apparently stall. If I'm running ping continuously, for instance, it >> will at some point stop receiving replies. Then, sometime later, immediately >> if I use the "reassociate" command in wpa_cli, the connection will fix >> itself and all the packets I didn't get earlier get delivered at once: >> hundreds of ping replies, for instance, some with time stamps minutes in the >> past. No data is actually lost, though. >> >> I think the issue is that the driver does not actually support powersave >> mode (maybe it should?) but reports to the AP that it does: >> >>> ifconfig wlan0 list sta (this is on the AP) >> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >> 80:1f:02:cc:47:a9 1 11 11M 8.5 0 5526 55712 EPS AE RSN >> >> I don't know enough about wireless to fix this, but the AP waiting for a >> powersave poll and never getting one seems consistent with the problem. Is >> there a simple way just to disable advertising this? > When it next stalls, check ifconfig wlan0 and ifconfig urtwn0 - see if > OACTIVE is set. > > I know iwn and ath had problems in the past where OACTIVE handling was > plain broken (wasn't behind locks) and in an SMP, preemptive world > things got gunked up. > OACTIVE is not set when it stalls. It also appears that only the RX path is stalled: transmitted packets make it, at least some of the time, to their destination when this happens. -Nathan