From owner-freebsd-bugs@FreeBSD.ORG Mon Feb 20 02:40:10 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DFE01065676 for ; Mon, 20 Feb 2012 02:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5EA8FC0C for ; Mon, 20 Feb 2012 02:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1K2eA6G073887 for ; Mon, 20 Feb 2012 02:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1K2eAEX073886; Mon, 20 Feb 2012 02:40:10 GMT (envelope-from gnats) Resent-Date: Mon, 20 Feb 2012 02:40:10 GMT Resent-Message-Id: <201202200240.q1K2eAEX073886@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Adrian Chadd Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72E29106566B for ; Mon, 20 Feb 2012 02:30:31 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1518FC0C for ; Mon, 20 Feb 2012 02:30:31 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q1K2UVf1094778 for ; Mon, 20 Feb 2012 02:30:31 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q1K2UV3r094777; Mon, 20 Feb 2012 02:30:31 GMT (envelope-from nobody) Message-Id: <201202200230.q1K2UV3r094777@red.freebsd.org> Date: Mon, 20 Feb 2012 02:30:31 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/165306: [ath] race conditions between scanning and beacon timeout programming X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 02:40:10 -0000 >Number: 165306 >Category: kern >Synopsis: [ath] race conditions between scanning and beacon timeout programming >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 20 02:40:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: 9.0-RELEASE i386 w/ HEAD net80211/ath >Organization: >Environment: >Description: There seem to be issues where net80211 doesn't quite get the "beacon miss" notification. It stays associated, the beacon interrupt/notification isn't occuring. Adding on reset/beacon debugging (0x20 + 0x80) on ath0 (sysctl dev.ath.0.debug=0xa0) didn't show any beacon miss interrupts, software or hardware. This is with one VAP STA on an AR9280. What I think is happening is: * the transition to -> RUN doesn't program in any beacon timers by default - it waits for the first beacon to be RX'ed before it programs in timers; * but if it loses connectivity during a scan, the beacon timers won't ever be reprogrammed, as no beacons will occur. So it stays associated. >How-To-Repeat: The above should be doable to reproduce - just enable beacon debugging, then do a scan and kill the AP whilst the station is scanning. >Fix: It may be that we need to: * program in some beacon TSF value for the initial state transition to RUN, and hope that a new beacon will come in and reprogram the timers. * .. or also enable swbeacon support too for single-VAP STA mode? >Release-Note: >Audit-Trail: >Unformatted: