Date: Sat, 30 Dec 2006 19:39:54 -0800 From: Sam Leffler <sam@errno.com> To: JoaoBR <joao@matik.com.br> Cc: freebsd-stable@freebsd.org Subject: Re: ath0 timeout problem - again Message-ID: <4597310A.4020807@errno.com> In-Reply-To: <200612301950.29821.joao@matik.com.br> References: <200612282002.11562.joao@matik.com.br> <4596CE08.3090104@errno.com> <200612301950.29821.joao@matik.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <hostap> >> 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. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4597310A.4020807>