ath0 timeout problem - again

[Sam Leffler]

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