Hello there...

Everytime we block any wireless client radio MAC through the Access list of the AP-Bridge, the client radio keeps attempting to connect and naturally gets rejected and drops temporarly. Problem is we have to use "Default Authentication" on the AP with no Encryption. However, the persistent blocked client radios keep trying to connect and eventually timeouts start occuring on the APs. Why is it that when even with older non-MT radios we block clients by MAC, we never have problems and with MT this has been a problem for us for years.... Seems MT simply can't permanently ban a client radio or we are doing something wrong. Increase the number to 3 clients and the result is a DoS attack on the AP. The problem is not random clients only, it is any client. Say even when one of our own client's radios gets shifted by wind and we have to temporarly block the client; all hell breaks loose on the tower until that client's allignment is sorted.

Is there a way to stop this situation possibly with "Disconnect timeout", "On Fail Retry," Signal Strength limits, specific encryption for the blocked radio or something? Anyone knows? Thx

Have you tried using "hide ssid" option?
Then they shouldn't connect until they know the SSID for sure.
I agree that this is not right, the driver should have been optimized to discard packets as early as possible.

I have a similar problem. My AP stops responding altogether on ether1 and on the clients end logs show 'authentication timeout'. Would enabling wpa fix this or does mac auth come first?

@sten : would hide ssid work? surely that feature is only to hide from people. ie if i guessed the ssid and the ap didnt require mac auth i would connect to the ap? the hide ssid would not work for me anyway as some radios that are not mikrotik based cant connect at all.

I also wonder about the client load of your AP and how many APs you have in the same area, frequencies etc

otherwise there should be some sort of rule to deny the client after a certain amount of tries?

I have a similar problem. My AP stops responding altogether on ether1 and on the clients end logs show 'authentication timeout'. Would enabling wpa fix this or does mac auth come first?

@sten : would hide ssid work? surely that feature is only to hide from people. ie if i guessed the ssid and the ap didnt require mac auth i would connect to the ap? the hide ssid would not work for me anyway as some radios that are not mikrotik based cant connect at all.

I also wonder about the client load of your AP and how many APs you have in the same area, frequencies etc

otherwise there should be some sort of rule to deny the client after a certain amount of tries?

Generally speaking,...

Hide SSID is no security feature. But you do get the benefit of not having all those roaming laptops and phones trying to connect (because the SSID is unknown to them). If the CPE radio's can't authenticate on unknown SSID's (you would have to enter the SSID on the CPE first of course), then it's not behaving properly and that should be considered a bug on the CPE end.

MAC based access-list should work before WPA (although not tested). MAC based access-lists are easily evaded though and should not be considered as a real security feature. WPA would add the necessary encryption for any real security.

It's generally much better to white list the clients that are allowed to connect rather than making a mechanism that blocks a client after too many tries (when one of your CPE's is experiencing problems, should it be locked out?). Every time a client tries to connect, there will be a lot of association traffic that generally takes precedence over normal traffic. These association requests are also sent at the basic rate, burning up a lot of valuable air time. Dynamic-ack causes most of this traffic so YMMV. WPA adds additional traffic.
MAC access-list will prevent the AP using up all this air time on rogue clients but it won't prevent the CPE from transmitting lots of association requests (which burns up airtime as well), hence the hidden SSID feature would be most helpful.

I know this may not be cost effective for you but we found long ago that we needed two AP's per tower if not more in two basic types - One for 'Roaming Clients" or hotspot - and all our sectors and dedicated AP's (sectors or omnis) hidden by way of nStreme/NV2 or Airmax with channel offsets on. When you do this you really don't care about the hotspot stuff.

Rod Neal
HTWC.biz