CAPsMAN HAP AC2 and CAP AC

Zacharias · Sun Apr 19, 2020 7:05 pm

disconnected, registered to other interface

It is what it is... Your client connected to another AP...

And don't tell me about fucking ACL or something.... It does'nt work.

Access list is just a way to improve the Roaming, it is something like a workaround..nothing more nothing less...

And don't fucking tell me about "roaming is completely controlled by the clients"...

Mikrotik does not support yet 802.11k or 802.11r protocols that provide a better roaming... 'k' works with neighbor list reports available to the Client and 'r' provides a seamless roaming, really great for voice applications, and what it actually does is the client authenticates it self to other APs(before the roam process) so when it is time to roam it has been already authenticated thus we have an ultra fast transition to the next AP...

But... This does not change the Fact that the client makes the decisions... Either if we talk about 802.11r or 802.11k or simple roaming...

heidarren · Sun Apr 19, 2020 8:45 pm

Your log seems weird, the client will decide to connect the far AP which has almost -90dBm instead of keeping connection with the closer AP which is about -45dBm, I can imagine you were holding your phone just beside the AP and it was keep jumping between both AP, it happens sometimes but only when both AP’s signal are nearly identical. My 1st question will be does it happen to all your devices or just this Xiaomi phone? Have you try to forget the network and connect again with your phone?

anav · Sun Apr 19, 2020 9:43 pm

I can play this game......
What an effing piece of shit that Xiaomi Redmi Note 3 pro SE is.
How could one have the audacity to actually try to make such trash work with the classic elegant MT device??

Madcatua · Sun Apr 19, 2020 10:44 pm

Access list is just a way to improve the Roaming, it is something like a workaround..nothing more nothing less...
But... This does not change the Fact that the client makes the decisions... Either if we talk about 802.11r or 802.11k or simple roaming...

ACL causes connection drop and re registering every 1-2 minutes. Cause phone is trying to roam anyway.
Client makes wrong decision on 6.45.5. But it's all ok(except battery drain) it on 6.47.beta54. So problem is not in phone. There must be a reason...

Your log seems weird, the client will decide to connect the far AP which has almost -90dBm instead of keeping connection with the closer AP which is about -45dBm, I can imagine you were holding your phone just beside the AP and it was keep jumping between both AP, it happens sometimes but only when both AP’s signal are nearly identical. My 1st question will be does it happen to all your devices or just this Xiaomi phone? Have you try to forget the network and connect again with your phone?

Yep. Phone 3 feet from the CAP AC.(or near hAP AC2). Or at 2.4Ghz...
Not only with this Xiaomi. Another Xiaomi, but it happend very rare:

21:52:45 caps,info 64:CC:2E:B9:38:7B@hapac5 connected, signal strength -86
21:52:45 caps,info 64:CC:2E:B9:38:7B@capac5 disconnected, registered to other interface
21:52:48 caps,info 64:CC:2E:B9:38:7B@capac5 connected, signal strength -41
21:52:48 caps,info 64:CC:2E:B9:38:7B@hapac5 disconnected, registered to other interface

Forgetting and reconnecting does not help.

P.S. This started only when phone in trying to deep sleep.

heidarren · Sun Apr 19, 2020 11:08 pm

Regarding the battery drain, did you set "Multicast Helper" to full? I noticed if I have this enabled, my client will wake up every second as the "Last Activity (s)" shows in "Registration" will always below 1.00, this may indicated that clients are awaken in every second, and that's drained my battery

Madcatua · Sun Apr 19, 2020 11:12 pm

Regarding the battery drain, did you set "Multicast Helper" to full? I noticed if I have this enabled, my client will wake up every second as the "Last Activity (s)" shows in "Registration" will always below 1.00, this may indicated that clients are awaken in every second, and that's drained my battery

Multicast Helper does not set at all.

heidarren · Mon Apr 20, 2020 9:29 am

What about rates setting? Some android devices will draw back to 802.11b rate when sleeping, it will drop connection if your AP doesn't do 802.11b rate

Madcatua · Mon Apr 20, 2020 3:53 pm

What about rates setting? Some android devices will draw back to 802.11b rate when sleeping, it will drop connection if your AP doesn't do 802.11b rate

Switched from 5ghz-onlyac and 2ghz-onlyn to 5ghz-a/n/ac and 2ghz-bgn....
Nope. Same thing with roaming. No battery drain.

P.S. Rollback to LT 6.44.6 does not help too.

Zacharias · Mon Apr 20, 2020 4:20 pm

@Madcatua as i ve already explain, the Client plays the most important role in roaming, or at least an important one, since the client is the one who takes the decisions...
So, change your client device and make a test with a better one...

Madcatua · Mon Apr 20, 2020 6:14 pm

Why client decision to roam depends on firmware of router?
Explain this.

Redmi Note 3/Mi5s plus is not so old or buggy devices...
The router must do his job! I do not have to select compatible devices with it. You can't explain that to boss or client.

Zacharias · Mon Apr 20, 2020 8:23 pm

You can't explain that to boss or client.

This is totally irrelevant...

The router must do his job!

I've already explained that the station roaming, at least at your problem, has to do with the client device... If the device does not roam to an AP with better signal its the device's problem...
The router (CapsMan) has nothing to do with that...
Again, a workaround in your case would be to use the access list, the fact that did not work for you is because most probably you had a wrong configuration under the list...
Example:

/caps-man access-list
add action=accept allow-signal-out-of-range=10s disabled=no interface=any \
    signal-range=-70..120 ssid-regexp=""
add action=reject allow-signal-out-of-range=10s disabled=no interface=any \
    signal-range=-120..-71 ssid-regexp=""

The above rules under CapsMan Access list will allow any device connected to any interface to stay connected as long as the signal is in the Range of -70..120 dbm... In case it gets out of that range it will be allowed for 10 Seconds only, after that it will procceed to the next rule that will reject the Client device, and hopefully the client device (because yes it happens) will not try to connect again to the worst signal AP but move on to a better One...
At the second rule above, you can skip the signal-range and let it blank, it will do the same thing and reject the device...

Madcatua · Tue Apr 21, 2020 12:48 am

With acl phone is trying to roam anyway. Got connection drop(acl) and reconnect again to closest AP with 4way handshake, dhcp... And repeat it again till 30 seconds.
And again and again. After some time it stop connecting at all.

Zacharias · Tue Apr 21, 2020 1:05 am

What was the allowed signal range you did set in the Access List for a client to stay connected?
Can you export and post the Access List rules ?

Madcatua · Tue Apr 21, 2020 1:15 am

I have acl only for comments for registration table.
-120..+120 allow.
For exapmle:
add action=accept comment=RN3Pro disabled=no mac-address=64:CC:2E:B9:38:7B signal-range=-120..120 ssid-regexp=""

Zacharias · Tue Apr 21, 2020 6:56 pm

add action=accept comment=RN3Pro disabled=no mac-address=64:CC:2E:B9:38:7B signal-range=-120..120 ssid-regexp=""

This is wrong, does it look like the rules i posted earlier? No... That rule just accepts every signal range...

CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC

Re: CAPsMAN HAP AC2 and CAP AC