Date: Sat, 30 Dec 2006 12:37:28 -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: <4596CE08.3090104@errno.com> In-Reply-To: <200612282002.11562.joao@matik.com.br> References: <200612282002.11562.joao@matik.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4596CE08.3090104>