ath0 timeout problem - again

JoaoBR joao at
Sat Dec 30 14:50:38 PST 2006

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

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

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? 

> 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.



A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik

More information about the freebsd-stable mailing list