From owner-freebsd-stable@FreeBSD.ORG Sat Dec 30 20:37:30 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9264416A4D4 for ; Sat, 30 Dec 2006 20:37:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6CD4A13C43E for ; Sat, 30 Dec 2006 20:37:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kBUKbTD8020892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Dec 2006 12:37:30 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4596CE08.3090104@errno.com> Date: Sat, 30 Dec 2006 12:37:28 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: JoaoBR References: <200612282002.11562.joao@matik.com.br> In-Reply-To: <200612282002.11562.joao@matik.com.br> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ath0 timeout problem - again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2006 20:37:30 -0000 JoaoBR wrote: > 572 cabq frames transmitted > 11 cabq xmit overflowed beacon interval > > media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b So one other thing came to mind. If your ap is operating in 11b and you have many multicast frames q'd up for power save stations then they can effectively saturate the network if they are being trasnmitted at a low tx rate (which they would be). This can effectively DOS your wireless network because the frames are burst immediately following the beacon. The driver limits the burst interval so it does not overflow into the next beacon but it's allowed to fill all available time to the next beacon frame (something I've considered changing for just the reason I described). This has always been an issue. You might try rate limiting these frames or just hack the driver to violate the spec and not buffer them for tx after the beacon (to see if your problem goes away). Further, if you have a machine with a crappy pci bus (such as !4801 soekris boards) it's entirely possible that you are hoarding the bus with these long transmits s.t. other problems are occurring. I do not recommend building ap products out of such equipment. (No disrespect to the 4501, et al they just had substandard pci bus operation.) Sam