From owner-freebsd-stable@FreeBSD.ORG Sat Dec 30 22:50:38 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 B5D9F16A407 for ; Sat, 30 Dec 2006 22:50:38 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2721613C483 for ; Sat, 30 Dec 2006 22:50:37 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kBUMn6Pa015987; Sat, 30 Dec 2006 19:49:06 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Sam Leffler Date: Sat, 30 Dec 2006 19:50:29 -0200 User-Agent: KMail/1.9.3 References: <200612282002.11562.joao@matik.com.br> <4596CE08.3090104@errno.com> In-Reply-To: <4596CE08.3090104@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612301950.29821.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean 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 22:50:38 -0000 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 we block incoming traffic, we sell internet access so there will no access = to=20 the station which might match the case you brought up, the station request= =20 access to a site and get reply, when the station "sleeps" (if) then there i= s=20 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=20 did exactly what you mentioned.=20 The tx buffer on the AP, once getting used is never released even if never= =20 getting to fill it up to the configured limit - this I consider so far a=20 problem but not related to the problem we discuss but let me ask, certainly the same problem could come up when for instance = the=20 client has a bad signal (bad caox or connector, antena misplaced or local=20 interference) and the AP can not tx to this station in this exact moment wh= en=20 his signal drops right?=20 > > 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 beca= use=20 on POPs where this special case of traffic do not appear we have them up fo= r=20 months even with higher traffic as I mentioned before. thank you for your availability to help. =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br