From owner-freebsd-stable@FreeBSD.ORG Sun Dec 31 03:39:54 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 B0B4616A403 for ; Sun, 31 Dec 2006 03:39:54 +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 7382113C455 for ; Sun, 31 Dec 2006 03:39:54 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kBV3dpiN022707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Dec 2006 19:39:54 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4597310A.4020807@errno.com> Date: Sat, 30 Dec 2006 19:39:54 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: JoaoBR References: <200612282002.11562.joao@matik.com.br> <4596CE08.3090104@errno.com> <200612301950.29821.joao@matik.com.br> In-Reply-To: <200612301950.29821.joao@matik.com.br> X-Enigmail-Version: 0.94.1.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: Sun, 31 Dec 2006 03:39:54 -0000 JoaoBR wrote: > On Saturday 30 December 2006 18:37, Sam Leffler wrote: >> 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. > > > hum, let's see ... > > this is an ISP environment > as unlikely the AP goes to sleep while rx/tx the client station either Don't know where this comment came from. Noone ever suggested the machine operating as an ap goes to sleep. > > we block incoming traffic, we sell internet access so there will no access to > the station which might match the case you brought up, the station request > access to a site and get reply, when the station "sleeps" (if) then there is > no considerable tx to it > > >> 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). > > ok I understand, this certainly is another point we have problems with but we > did exactly what you mentioned. > > The tx buffer on the AP, once getting used is never released even if never > getting to fill it up to the configured limit - this I consider so far a > problem but not related to the problem we discuss Sorry I do not understand this but you say it is not related. > > > but let me ask, certainly the same problem could come up when for instance the > client has a bad signal (bad caox or connector, antena misplaced or local > interference) and the AP can not tx to this station in this exact moment when > his signal drops right? Sorry, again I do not understand your point. I guess you're asking how do people deal with radio sources jamming the frequency, there's nothing you can do if someone doesn't honor the 802.11 protocols. > > > >> 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.) >> > > ok, like said before we use PCs and the MBs we use are pretty reliable because > on POPs where this special case of traffic do not appear we have them up for > months even with higher traffic as I mentioned before. > > > thank you for your availability to help. > >