Reply
Regular Member
Posts: 441
Registered: ‎09-28-2017
Kudos: 121
Solutions: 31

Re: Everything is great - not so much - Blocked by access control is out of control

@mathieuh I'm obviously not getting my point across.  Totally my fault.

 

I agree that the "problem" is MAC filtering.  What I'm trying to convey is that any time any client tries to access - associate - otherwise communicate with an SSID that has that particular client blocked or MAC filtered it will be "blocked" and increment the appropriate counter.  This will happen even if that same client has access - is not blocked or MAC filtered - on the same AP.  You know how (some) clients have a setting like "try connecting to better SSID if available"?  When they scan and try connecting with an SSID on which they are being filtered, it will cause the alert and counter increment.  

 

Make sense?  Hope so.  Apologies if I still don't understand the problem.

Emerging Member
Posts: 82
Registered: ‎12-12-2016
Kudos: 101
Solutions: 1

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

@nc2kft wrote:

"only internal SSID has MAC filter enabled guest SSID does not"

 

Any MAC being filtered will increase the counter every time it tries to connect to an SSID with the filtering enabled.

 

The Insights page only shows those clients which have been outright blocked on the controller.  Any other clients being "blocked" by MAC filtering will not show up there, only in the logs.  I think this is the way I prefer it too.  You are upset at seeing the count, I don't want a possible massive list of such (MAC) blocked clients.  

 

Maybe a seperate page of those clients being MAC filtered, but for those of us using Cloud Keys, I want to use as little storage as possible.  Remote syslog is where they belong.

 

Just my 2 cents.


 

Not sure if I got you right but the one Samsung Mobile I have seen on one of my UAP was connected to the guest SSID and still the UAP fired plenty of "blocked" logs (see above).

 

In addition guest SSID has no encyption so it's open where internal SSID has WPA2. So unknown clients (guests) mostly connect automatically to the guest SSID where they proabably do not without any manual interaction to the internal SSID.

New Member
Posts: 29
Registered: ‎10-19-2017

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

@nc2kft I guess I wasn't clear enough myself.

 

None of my regular devices has the IoT SSID configured, and it is protected using WPA2, so no devices would try to connect automatically. No devices should try to associate with it unless for the couple configured (and in the whitelist)

Hence why I said no association failures should occur.

 

It is 100% a bug. Some kind of leak of the MAC filtering from one SSID onto another that shouldn't have any.

 

I guess, the clients blocked by guest control might end up causing the same kind of MAC filter bug/leak.

 

Edit: Also, as I mentioned before, this is not merely a problem of a counter being incremented. Since this issue started in October, I've had a constant 20-30% CPU utilization on my AP. Disabling MAC filtering on the IoT SSID caused the utilization to go back to a normal 2%.

Emerging Member
Posts: 82
Registered: ‎12-12-2016
Kudos: 101
Solutions: 1

Re: Everything is great - not so much - Blocked by access control is out of control


@mathieuh wrote:

@nc2kft I don't think this issue has anything to do with Guest control or blocked clients.

 

I think the issue is with MAC Filtering being enabled on one SSID and triggering association failures logs (but not actions) when a client connects to another SSID which has no MAC filtering.

 

While @marbl  has guest control enabled, he also has MAC filtering on his internal SSID, and I'm guessing it's a whitelist.

 

In my case, no stations besides a couple IoT devices attempt to connect to the IoT dedicated SSID. No association failures should occur, yet millions per day do if I have the Mac filtering enabled on the IoT SSID.


You are right MAC filter for internal SSID is based on whitelist.

I Also don't think this issue is based guest controll. More I belive it's kind of buggy logging in case you have more than one SSID but MAC filtering on only one SSID. That's because guest access on the guest SSID works pretty well and and also MAC filtering does on internal SSID. Meaning I do not have any degradation of service, just the huge counters on the dashboard which are missleading and some strange logs on the UAPs which may be counted on the dashoard....

Emerging Member
Posts: 82
Registered: ‎12-12-2016
Kudos: 101
Solutions: 1

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

@mathieuh wrote:

@nc2kft I guess I wasn't clear enough myself.

 

None of my regular devices has the IoT SSID configured, and it is protected using WPA2, so no devices would try to connect automatically. No devices should try to associate with it unless for the couple configured (and in the whitelist)

Hence why I said no association failures should occur.

 

It is 100% a bug. Some kind of leak of the MAC filtering from one SSID onto another that shouldn't have any.

 

I guess, the clients blocked by guest control might end up causing the same kind of MAC filter bug/leak.

 

Edit: Also, as I mentioned before, this is not merely a problem of a counter being incremented. Since this issue started in October, I've had a constant 20-30% CPU utilization on my AP. Disabling MAC filtering on the IoT SSID caused the utilization to go back to a normal 2%.


exactly my understanding as well.... :-)

 

EDIT: my UAP-AC-Pros have around 70% Mem usage, the UAP-HD around 32% with MAC filtering enabled

Regular Member
Posts: 441
Registered: ‎09-28-2017
Kudos: 121
Solutions: 31

Re: Everything is great - not so much - Blocked by access control is out of control


@marbl wrote:

Found plenty of such logs on the UAPs but non of the MAC addresses can be found as guests or internal devices:


Not trying to be dense, but if they've been blocked, they wouldn't be listed - depending on where they were blocked. 

 

For example: Using one of the listed events -

 

vap: ath1 This is the SSID and Band performing the block - 

navigate to Settings > Devices > Select an AP > WLANS

sta_mac: 78:28:ca:0b:ee:17  This is the MAC being "blocked" 

 

The reason there are so many events for the same MAC is that every time the client attempts to access the SSID (ath) in question, a new event is generated.  This can happen every few seconds.

 

If I still don't understand the problem, please try one more time.

 

 

New Member
Posts: 29
Registered: ‎10-19-2017

Re: Everything is great - not so much - Blocked by access control is out of control


@marbl wrote:

You are right MAC filter for internal SSID is based on whitelist.

I Also don't think this issue is based guest controll. More I belive it's kind of buggy logging in case you have more than one SSID but MAC filtering on only one SSID. That's because guest access on the guest SSID works pretty well and and also MAC filtering does on internal SSID. Meaning I do not have any degradation of service, just the huge counters on the dashboard which are missleading and some strange logs on the UAPs which may be counted on the dashoard....


How's your AP CPU utilization?

What happens if you disable MAC filtering on your internal SSID?

 

For me the change was pretty imediate and dramatic (for the number to fall visibly, filter to the last hour of events in the wifi dashboard)

Emerging Member
Posts: 82
Registered: ‎12-12-2016
Kudos: 101
Solutions: 1

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

@nc2kft wrote:

@marbl wrote:

Found plenty of such logs on the UAPs but non of the MAC addresses can be found as guests or internal devices:


Not trying to be dense, but if they've been blocked, they wouldn't be listed - depending on where they were blocked. 

 

For example: Using one of the listed events -

 

vap: ath1 This is the SSID and Band performing the block - 

navigate to Settings > Devices > Select an AP > WLANS

sta_mac: 78:28:ca:0b:ee:17  This is the MAC being "blocked" 

 

The reason there are so many events for the same MAC is that every time the client attempts to access the SSID (ath) in question, a new event is generated.  This can happen every few seconds.

 

If I still don't understand the problem, please try one more time.

 

 


ath1 is the internal SSID on the 2.4GHz Band which is protected by WPA2. So in this case the MAC filter would apply befor WPA authentication - does this makes sence? My expectation would have been that once a client is authenticated by WPA - THEN - the MAC filter is applied and not vice versa...

 

EDIT: and even if MAC filtering would be appliend before WPA then still the blocked clients which are reported on the dashboard should be listed under blocked clients list

Emerging Member
Posts: 82
Registered: ‎12-12-2016
Kudos: 101
Solutions: 1

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

@mathieuh wrote:

@marbl wrote:

You are right MAC filter for internal SSID is based on whitelist.

I Also don't think this issue is based guest controll. More I belive it's kind of buggy logging in case you have more than one SSID but MAC filtering on only one SSID. That's because guest access on the guest SSID works pretty well and and also MAC filtering does on internal SSID. Meaning I do not have any degradation of service, just the huge counters on the dashboard which are missleading and some strange logs on the UAPs which may be counted on the dashoard....


How's your AP CPU utilization?

What happens if you disable MAC filtering on your internal SSID?

 

For me the change was pretty imediate and dramatic (for the number to fall visibly, filter to the last hour of events in the wifi dashboard)


CPU is minimal on both models where memory stays stable for the UAP-HD but has increased ~10% on the UAP-AC-Pro over the last 24h (did the 4.0.21 upgrade yesterday).

Memory did not change on the UAP-HD models but dropped around 20% when disabling MAC filtering on the AC-Pros.

 

Regular Member
Posts: 441
Registered: ‎09-28-2017
Kudos: 121
Solutions: 31

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

@marbl wrote:

 

ath1 is the internal SSID on the 2.4GHz Band which is protected by WPA2. So in this case the MAC filter would apply befor WPA authentication - does this makes sence? My expectation would have been that once a client is authenticated by WPA - THEN - the MAC filter is applied and not vice versa...

 

EDIT: and even if MAC filtering would be appliend before WPA then still the blocked clients which are reported on the dashboard should be listed under blocked clients list


Now we're getting somewhere.  Blocking and filtering do take precedence.  If a unit is to be blocked, there's no sense in performing the handshake and confirming the security key.  If we are going to perform a block, we are assuming the possibility of key sharing enabling a rogue device on a sensitive network, etc.  

 

As for displaying the clients, that's another matter.  My guess is that since we were able to block a device way before the display widgets, it just hasn't been on the radar yet - one of those Beta features still in development.

 

Seems like were finally on the same page. Cheers2

New Member
Posts: 3
Registered: 2 weeks ago

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

I have filtering setup on one of my SSIDs in a business area that isn't insanely busy, but there are enough people around. My logs show tons of entries for devices that I'm sure aren't attempting to connect due to it's unlikely over 100 unique MACs would try to connect tons of times to a hidden SSID in a day. So it's as if entries are being created just by devices pinging to see what's out there. As with others, if I disable filtering I stop getting the messages except for a few devices I manually blocked. As of this post I'm at 349688 Blocked by access control.

The chat support guy said I can ignore the messages if I'm not facing any issues... so yeah there's that...

Regular Member
Posts: 441
Registered: ‎09-28-2017
Kudos: 121
Solutions: 31

Re: Everything is great - not so much - Blocked by access control is out of control

@likeafoxx This is what I would expect if you enable MAC filtering and are using a white list.  Any client, not on the list, will cause an event to be generated each and every time it tries to access the SSID in question for any reason whatsoever.  In reading the posts regarding the ACLs, the major point of contention is the high count displayed.  Maybe if only the number of unique MACs being blocked were displayed on the dashboard and the MACs would be available in the Insights area, it would be better received.  

New Member
Posts: 29
Registered: ‎10-19-2017

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

I'm sorry but a probe is not the same as an association attempt, or at least shouldn't be.

This does help explain why I have a million blocks in a day, I live in a busy city.

 

Also, this "blocking" shouldn't burn up 30% CPU of my AC-Lite.

 

Still a bug in my opinion.

Regular Member
Posts: 441
Registered: ‎09-28-2017
Kudos: 121
Solutions: 31

Re: Everything is great - not so much - Blocked by access control is out of control

Not so much a bug as a work in progress - From the controller release notes:

 

  • Some statistics on the dashboard are still under development. Please share any and all feedback!
New Member
Posts: 3
Registered: 2 weeks ago

Re: Everything is great - not so much - Blocked by access control is out of control

@nc2kft I think even the MAC count could be too much for anyone that has ACL setup in a populated area. There's a popular food place next to our office building which I'm sure some of the phones there hit our APs. It would be different if they could get it smarter so it only counted attempts to connect. I do agree that a list would be nice regardless as I had to export the messages file with hundreds of thousands or more of lines and strip the MACs. Thankfully excel will remove duplicates. The tech also did say the "dashboard is under development, we will try to improve it in future versions"

@mathieuh agreed that it should only be for actual attempts to give that message. "That is because if clients try to connect even with incorrect password, thos alerts are shown" - Ubiquity support. We both know that many people aren't trying to connect to us. My AP-AC-Pros are consistently at 45%-60%. Thankfully most of my users are wired at their desks and people don't complain about speeds, but that isn't the point at all. I also get *tons* of inform messages going from the APs to the controller (on the controller's log). Do you show those too? Regardless, my stuff got sent to L2 support and if they provide helpful stuff I'll let you know.
Emerging Member
Posts: 78
Registered: ‎10-20-2016
Kudos: 4
Solutions: 2

Re: Everything is great - not so much - Blocked by access control is out of control


@mathieuh wrote:

I'm sorry but a probe is not the same as an association attempt, or at least shouldn't be.

This does help explain why I have a million blocks in a day, I live in a busy city.

 

Also, this "blocking" shouldn't burn up 30% CPU of my AC-Lite.

 

Still a bug in my opinion.


I can agree 100% with the statement that it is a "bug".

Regular Member
Posts: 441
Registered: ‎09-28-2017
Kudos: 121
Solutions: 31

Re: Everything is great - not so much - Blocked by access control is out of control

@likeafoxx 

 

"I think even the MAC count could be too much for anyone that has ACL setup in a populated area."

I don't necessarily disagree.  Just saying, if a count is to be displayed, it would be better to display the unique MACs rather than the current count.  

 

"It would be different if they could get it smarter so it only counted attempts to connect."

Work in progress?  

 

"I do agree that a list would be nice regardless as I had to export the messages file with hundreds of thousands or more of lines and strip the MACs."

I'm still trying to warm to this idea just because of your scenario.  Anyone using a Cloud Key will want to keep the logs to a minimum - onboard storage.  I actually prefer setting up the remote syslog server, but can see where listing them in the insights area may be beneficial.

 

"...I also get *tons* of inform messages going from the APs to the controller... Do you show those too?..."

Yes, we can all get these and I definitely don't like it.  It would be better if they only logged the missed heartbeats instead.

Emerging Member
Posts: 82
Registered: ‎12-12-2016
Kudos: 101
Solutions: 1

Re: Everything is great - not so much - Blocked by access control is out of control

[ Edited ]

@nc2kft wrote:

@likeafoxx This is what I would expect if you enable MAC filtering and are using a white list.  Any client, not on the list, will cause an event to be generated each and every time it tries to access the SSID in question for any reason whatsoever.  In reading the posts regarding the ACLs, the major point of contention is the high count displayed.  Maybe if only the number of unique MACs being blocked were displayed on the dashboard and the MACs would be available in the Insights area, it would be better received.  


 

Isn't the question in which order? For example:

  1. if i have a WPA protected SSID and a client which does not have the credentials I would not expect an MAC event. Even if this client is either blacklisted or not on the white list
  2. If the same SSID and client from 1) has the credentials and i not white or it would be blacklisted - then I would expect an event
  3. If an open SSID has MAC filtering then i would expect an event

So the magic question to me is, does MAC filtering apply befor WPA handshake?

 

The first example does generate huge amount of false positives (+600000 in my case) because a client just passing a WPA protected SSID is not per default trying to enter the network. Here it would make sence to have the same sort of logs/counters for the case a client tires to access the SSID with wrong credentials and the MAC events once the client is connected but not on white list or is blacklisted. So two different counters/logs one for MAC filtering (which applies after WPA handshake) and one for WPA handshake errors becaus of wrong credentials. This would generate max transparency to the network...

New Member
Posts: 3
Registered: 2 weeks ago

Re: Everything is great - not so much - Blocked by access control is out of control

@nc2kft Thankfully we can change the logging level from info to warn or error per device if storage became an issue. Unfortunately though it seems this would hide actual attempts to get in to the network, but I have no practical way of sorting out which is which right now so that's a moot point.
Member
Posts: 107
Registered: ‎12-19-2009
Kudos: 7

Re: Everything is great - not so much - Blocked by access control is out of control

I too have a steadily increasing count for "Blocked by access control".  But I do not have mac filtering enabled for any of my APs.  I did for a while, but that SSID is disabled (and now deleated).

 

Just noticed after upgrading to 5.10.12.0

 

Devices are on 4.0.22.9996

 

Reply