From owner-freebsd-current@FreeBSD.ORG Sat May 28 18:08:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E03316A41F for ; Sat, 28 May 2005 18:08:43 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7E0643D4C for ; Sat, 28 May 2005 18:08:42 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.90] ([66.127.85.90]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j4SI8Xms077746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 May 2005 11:08:33 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4298B3A9.9050906@errno.com> Date: Sat, 28 May 2005 11:08:41 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emil Mikulic References: <20050522110627.GA48162@dmr.ath.cx> <4290B89E.1040107@errno.com> <20050528100219.GC75204@dmr.ath.cx> In-Reply-To: <20050528100219.GC75204@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 18:08:43 -0000 Emil Mikulic wrote: > On Sun, May 22, 2005 at 09:51:42AM -0700, Sam Leffler wrote: > >>Emil Mikulic wrote: >> >>>At home I have a FreeBSD 6-CURRENT machine with an ath card acting as >>>an access point. Every once in a while, wireless traffic stops and I >>>have to log in to this machine and manually bounce the interface to >>>get it going again. >> >>When this happens can you see beacons being xmit'd by the ap? Also >>the output of athstats (src/tools/tools/ath) may be useful. > > > As well as the AP machine, I have a FreeBSD 5-STABLE machine upstairs > which is a WiFi client. On which machine do you want me to turn debugging > on, and which flags? > > I've played around with /usr/src/tools/tools/ath/athdebug.c and > /usr/src/tools/tools/ath/80211debug.c before. > > What I remember is: > > - using one of the two tools to set some some flag lets me see beacons > =) > > - not to turn on certain flags on the AP machine since it has a serial > console and the flood of debugging output makes it grind to a halt > =/ > > Is there an easy way around this? Or do I only need to watch for > beacons on the client machine? I thought you had a machine using the ath driver and acting as an ap. You said periodically that machine would stop operating correctly and you had to mark the interface down+up to revive it. Assuming this I said, when the machine acting as an ap stops working can you see still see beacon frames being transmitted? To do this you need to have another machine. If the other machine is a client to the ap and using an ath card then 80211stats should show the count of beacon frames processed growing. Otherwise you can use tcpdump on the other machine to see beacon frames using something like: tcpdump -i ath0 -y IEEE802_11 or if it's not any ath card then you may need to do something different. If your problem is that the ap stops broadcasting beacons then all data frames will backup behind because normal data frames are queued on a different h/w tx queue that will be blocked by the inability to xmit the beacon frames. This condition is usually described as the "stuck beacon problem". I have a fix for this problem that I haven't committed yet. Sam