Hi there,

I have a little interesting issue with CAPsMAN. Well, let's say it works but it does not work....

Area:
Heavy AP concentration of mobile 2.4GHz APs. So 2.4 is not really favoured. Very few AC capable APs, thus spectrum is fairly open. Main boardroom is 20x6 meters and can host around 25 people at the same time.

Kit:
1. RB3011 as edge and CAPsMAN controller
2. PowerBox (RB960PGS-PB) as in-ceiling splitter to four APs
3. Four APs (RbcAPGi-5acD2nD), roughly 20m apart

Base Config:
1. Three SSIDs per freq band (both on 2.4 and 5.8GHz)
2. Full roaming on all APs required
3. Only WPA2-PSK with aes ccm encryption
4. Wireless key per SSID is complex passwords containing all kinds of characters
5. RB3011 to firewall between the SSIDs as they are on separate VLANs and need to get out to the internet

What I tried:
1. Normal CAPsMAN setup (keep it stupid, simple)
2. Added WPA PSK to the current WPA2-PSK setup
3. Added tkip encryption to the already setup aes ccm encryption
4. Set a Group-key Update value of 30mins
5. Created a datapath on a bridge per SSID, each bridge participates in its own VLAN. Local forwarding and client2client forwarding disabled implicitly
6. Four channels created one for 2.4 and the rest on 5.8. Initially the TX power on the 2.4GHz was set very low to force devices to rather connect at 5.8 GHz. Band on 2.4GHz was set to g/n only and extension channel implicitly disabled. On the 5.8 channels the band was set to n/ac, TX power fair for indoor use and eC extension channel used.
**During my troubleshooting I now enabled all bands on 2.4 (b/g/n) and 5.8 (a/n/ac)
7. Six configurations created, one pair per SSID. This allows to TX the same SSID on both 2.4GHz and 5.8GHz.
**Every CAPs config has a name, mode set to AP, SSID, distance set to dynamic, hw retries set to 15, hw protection mode set to rts/cts, disconnect timeout set to 15sec, keepalive frames are enabled, country set to south africa, max station count set to 30 (this is 30 devices per ap right?), multicast helper to full (found that some devices likes this more), enabled HT TX/RX Chains 0 and 1 with a HT guard level of any.
**channel config mentioned in point 6 above
**no data rates set, some devices (most on 2.4 only does not like if any data rate is configured)
**Datapath set as above
**and Security as well.
8. CAPs Provisioning is not used
9. Static CAP interfaces were created, one per SSID, AP and frequency. One SSID is configured on the main interface using the same MAC address as the designated AP with two slave devices for the remaining SSIDs. Unique MAC IDs were created per SSID. ****This is exactly how the provisioning service will configure it anyway.
10. Upgraded all devices to the latest ROS 3.17 (6.42.4 - hehe) with the latest firmware

Problems experienced:
1. Some client devices (mobile devices or laptops) simply goes into a connect/disconnect loop. Some devices shows (Obtaining IP address) and then simply does not connect. Others connects, gets IPs but then drops at a random interval
2. Many devices experience the infamous 4-way handshake nightmare
3. Some devices connects to the 2.4, then disconnects and connect to 5.8, get an IP issued by the DHCP server, but cannot access anything (towards the internet of course)
4. Many devices connects and disconnects for no reason.
5. Some device links perfectly, can VPN out to the internet and browse with no issues at all.
****I say SOME DEVICES as the problems do follow the device, but it is not manufacturer dependant. This is what stumps me. If it was iPhones I would say it is the aes ccm tkip combo. If it was Android devices it may be noise due to the 2.4GHz saturation. If it was HP laptops we could say it is the colour of the rainbow
6. Some devices simply sends a deauth: unspecified to the AP

Apologies for the essay, but I will go bald soon...

Howzit,

Either everyone has similar ussues or this issue is unknown or new

So, in order to verify if it is device density per AP or CAPsMAN's inability to deal with that level of device density per AP, I removed the AP from the CAPsMAN setup and did a local only setup.

Thus, the 2.4GHz radio's SSID is BLA-GST and has a virutal AP with SSID BLA-LTP, the same was done for the 5.8 radio.
When I do a spectral scan I can only see the 5.8GHz (physical AP) SSID being broadcast. The virtual AP on the 5.8 and both on the 2.4 does nothing. This it tells me it is not CAPsMAN causing the issues listed, but a bug in the Wireless package. Either accross the board or maybe just on these particular APs.

If anyone wants to log in remotely, this can be arranged at any time. I will allow access to all network devices (except the core switch). Please support, is there anything we can do? Anybody else maybe?

PS: I still have devices that can see all the various SSIDs, accepts the keys and then goes into a connect/disconnect loop. Both on CAPsMAN or without
PS2: On the AP (the RbcAPGi-5acD2nD or cAP ac (arm)), under the "Current Tx Power" tab, only the 2.4GHz radio displays values. Both virtual APs and the 5.8 radio does not.
PS3: For some reason in ROS 6.42.4 CAPsMAN creates twice the amount of virtual APs it is supposed to - See attached picture....

RaynoP
If you always think inside the box, you will never live on the outside

The forum might not be the best place to contact support, maybe send a mail to support@mikrotik.com ? More options on https://mikrotik.com/support

Do you have an export of your caps-man configuration?

Multiple virtual AP's might be because you have multiple slave configurations under your "provisioning" rules.
Another possibility is that the upgrade slightly altered the configuration and you have old and new interfaces mixed.

What happens when you delete the affected interfaces and do a /caps-man remote-cap provision ?

I don't have a clue about the issue with the AP with the standalone configuration, maybe start from scratch (factory reset) and a minimal configuration and build/test from there?

Howzit,

Either everyone has similar ussues or this issue is unknown or new

So, in order to verify if it is device density per AP or CAPsMAN's inability to deal with that level of device density per AP, I removed the AP from the CAPsMAN setup and did a local only setup.

Thus, the 2.4GHz radio's SSID is BLA-GST and has a virutal AP with SSID BLA-LTP, the same was done for the 5.8 radio.
When I do a spectral scan I can only see the 5.8GHz (physical AP) SSID being broadcast. The virtual AP on the 5.8 and both on the 2.4 does nothing. This it tells me it is not CAPsMAN causing the issues listed, but a bug in the Wireless package. Either accross the board or maybe just on these particular APs.

If anyone wants to log in remotely, this can be arranged at any time. I will allow access to all network devices (except the core switch). Please support, is there anything we can do? Anybody else maybe?

PS: I still have devices that can see all the various SSIDs, accepts the keys and then goes into a connect/disconnect loop. Both on CAPsMAN or without
PS2: On the AP (the RbcAPGi-5acD2nD or cAP ac (arm)), under the "Current Tx Power" tab, only the 2.4GHz radio displays values. Both virtual APs and the 5.8 radio does not.
PS3: For some reason in ROS 6.42.4 CAPsMAN creates twice the amount of virtual APs it is supposed to - See attached picture....

RaynoP
If you always think inside the box, you will never live on the outside

I find that sometimes LOG is my best friend. Look at your LOG and try to figure out what devices causing this issues. They might have some sort of signal strengh problem. You could try to put some accest list rules so APs will disconnect any clients that could cause troubles with signal. I could look into your routers to see what's what if you want. I'm certainly not a guru but I'm kinda good at solving these issues.

Good luck and have a nice day.

btw: did you upgraded from pre-6.40. RouterOS rr did your original setup already had post-6.40 RouterOS installed ?

The forum might not be the best place to contact support, maybe send a mail to support@mikrotik.com ? More options on https://mikrotik.com/support
Do you have an export of your caps-man configuration?
Multiple virtual AP's might be because you have multiple slave configurations under your "provisioning" rules.
Another possibility is that the upgrade slightly altered the configuration and you have old and new interfaces mixed.
What happens when you delete the affected interfaces and do a /caps-man remote-cap provision ?
I don't have a clue about the issue with the AP with the standalone configuration, maybe start from scratch (factory reset) and a minimal configuration and build/test from there?

True that, the forum probably isn't the best place, but I've been around for a while and know they are very busy and cannot always tend to the emails they get promptly (MUMs etc etc). And very often you get referred back to the forums anyway

I do only use the provisioning feature "once" in order to confirm the manual config I did, is correct, that is IF I use it. Mostly my configs just works by doing a manual config.
I beg to differ regarding interfaces remaining there after upgrades as CAPsMAN creates everything dynamically. If you implicitly disable local forwarding the interfaces it creates are virtual. So comms to CAPs controller = no virtual interfaces at all. If you use local forwarding then your statement is true AFAIK

The only way I could get rid of them was to remove CAPs control on the device and reboot it. It would not delete the "ghost" interfaces, no matter what I did....

The standalone config is as vanilla as you can get. I very seldom have to redo configs as I know how to fix or change what is required. I am by no means gloating in any way though, so please do not misinterpret my statement. We all human, we all make mistakes

Howzit,

Either everyone has similar ussues or this issue is unknown or new

So, in order to verify if it is device density per AP or CAPsMAN's inability to deal with that level of device density per AP, I removed the AP from the CAPsMAN setup and did a local only setup.

Thus, the 2.4GHz radio's SSID is BLA-GST and has a virutal AP with SSID BLA-LTP, the same was done for the 5.8 radio.
When I do a spectral scan I can only see the 5.8GHz (physical AP) SSID being broadcast. The virtual AP on the 5.8 and both on the 2.4 does nothing. This it tells me it is not CAPsMAN causing the issues listed, but a bug in the Wireless package. Either accross the board or maybe just on these particular APs.

If anyone wants to log in remotely, this can be arranged at any time. I will allow access to all network devices (except the core switch). Please support, is there anything we can do? Anybody else maybe?

PS: I still have devices that can see all the various SSIDs, accepts the keys and then goes into a connect/disconnect loop. Both on CAPsMAN or without
PS2: On the AP (the RbcAPGi-5acD2nD or cAP ac (arm)), under the "Current Tx Power" tab, only the 2.4GHz radio displays values. Both virtual APs and the 5.8 radio does not.
PS3: For some reason in ROS 6.42.4 CAPsMAN creates twice the amount of virtual APs it is supposed to - See attached picture....

RaynoP
If you always think inside the box, you will never live on the outside

I find that sometimes LOG is my best friend. Look at your LOG and try to figure out what devices causing this issues. They might have some sort of signal strengh problem. You could try to put some accest list rules so APs will disconnect any clients that could cause troubles with signal. I could look into your routers to see what's what if you want. I'm certainly not a guru but I'm kinda good at solving these issues.

Good luck and have a nice day.

btw: did you upgraded from pre-6.40. RouterOS rr did your original setup already had post-6.40 RouterOS installed ?

That is what gets me as well, I set additional logging rules to catch any form of CAPs or wireless errors, debug messages etc etc. Nothing. All you see is devices connecting and disconnecting - normal behaviour of wireless devices. That now excludes the couple of errors that does come through like "4-way handshake timeout" or "disconnecting due to access lists, reconnecting to another AP". I do have the ACLs that kicks a device off if its signal is too weak. I use it to force devices off of the 2.4GHz onto the 5.8GHz band. Thus my TX power on 2.4 is very very low.

What is striking though is, everything was working perfectly until we got 25 odd guys in there each with at least 2 devices. The APs are close enough that the ACL will kick one off to connect to another AP. Yes I staggered each APs' frequency and dropped TX power fo rall the good practice reasons

I generally update my CCR at home as soon as a new version comes out. Then after a day or five of smooth sailing I then roll it out to other devices. These particular devices has 6.40.something on. We baught them a little over three weeks ago. They still have that nice new smell hehe

Howzit,

Either everyone has similar ussues or this issue is unknown or new

So, in order to verify if it is device density per AP or CAPsMAN's inability to deal with that level of device density per AP, I removed the AP from the CAPsMAN setup and did a local only setup.

Thus, the 2.4GHz radio's SSID is BLA-GST and has a virutal AP with SSID BLA-LTP, the same was done for the 5.8 radio.
When I do a spectral scan I can only see the 5.8GHz (physical AP) SSID being broadcast. The virtual AP on the 5.8 and both on the 2.4 does nothing. This it tells me it is not CAPsMAN causing the issues listed, but a bug in the Wireless package. Either accross the board or maybe just on these particular APs.

If anyone wants to log in remotely, this can be arranged at any time. I will allow access to all network devices (except the core switch). Please support, is there anything we can do? Anybody else maybe?

PS: I still have devices that can see all the various SSIDs, accepts the keys and then goes into a connect/disconnect loop. Both on CAPsMAN or without
PS2: On the AP (the RbcAPGi-5acD2nD or cAP ac (arm)), under the "Current Tx Power" tab, only the 2.4GHz radio displays values. Both virtual APs and the 5.8 radio does not.
PS3: For some reason in ROS 6.42.4 CAPsMAN creates twice the amount of virtual APs it is supposed to - See attached picture....

RaynoP
If you always think inside the box, you will never live on the outside

I find that sometimes LOG is my best friend. Look at your LOG and try to figure out what devices causing this issues. They might have some sort of signal strengh problem. You could try to put some accest list rules so APs will disconnect any clients that could cause troubles with signal. I could look into your routers to see what's what if you want. I'm certainly not a guru but I'm kinda good at solving these issues.

Good luck and have a nice day.

btw: did you upgraded from pre-6.40. RouterOS rr did your original setup already had post-6.40 RouterOS installed ?

That is what gets me as well, I set additional logging rules to catch any form of CAPs or wireless errors, debug messages etc etc. Nothing. All you see is devices connecting and disconnecting - normal behaviour of wireless devices. That now excludes the couple of errors that does come through like "4-way handshake timeout" or "disconnecting due to access lists, reconnecting to another AP". I do have the ACLs that kicks a device off if its signal is too weak. I use it to force devices off of the 2.4GHz onto the 5.8GHz band. Thus my TX power on 2.4 is very very low.

What is striking though is, everything was working perfectly until we got 25 odd guys in there each with at least 2 devices. The APs are close enough that the ACL will kick one off to connect to another AP. Yes I staggered each APs' frequency and dropped TX power fo rall the good practice reasons

I generally update my CCR at home as soon as a new version comes out. Then after a day or five of smooth sailing I then roll it out to other devices. These particular devices has 6.40.something on. We baught them a little over three weeks ago. They still have that nice new smell hehe

I would like to have a look at your configuration in Winbox because I think this could be ACL problem. I'm sure you are very experienced but sometimes fine tunning of this setting is required along side with extensive testing. If some devices simply goes into connect/disconnect loop they might not be able to choose the right AP/BAND to connect to. Try fine tunning each CAP AP ACL and look at LOG files where different devices are connecting to. Other than that I think you configured everything just fine.
Please let me know on your progress

I would like to have a look at your configuration in Winbox because I think this could be ACL problem. I'm sure you are very experienced but sometimes fine tunning of this setting is required along side with extensive testing. If some devices simply goes into connect/disconnect loop they might not be able to choose the right AP/BAND to connect to. Try fine tunning each CAP AP ACL and look at LOG files where different devices are connecting to. Other than that I think you configured everything just fine.
Please let me know on your progress

Hi there,

Thank you for the assistance, but I think I found the issue. It simply is device density. I did a spectral analysis yesterday and found 48 x 2.4GHz APs and 17 x 5.8GHz APs while scanning from my laptop. As soon as all external interference (APs) were switched off after hours, most of our problems went away.

I still have the same devices which gives “4-way handshake” errors and the connect/disconnect loops – same devices. There are no ACLs, so it cannot be ACLs. IMHO I think a lot more R&D has to be done on CAPsMAN and the APs needs to be hardened to cope with high device density installations. We “upgraded” from one UBNT UniFi AC radio that could do what four CAP ACs cannot do. The devices giving the errors are brand new, so they use software and drivers that have been tried and tested by Samsung, Apple and HP for many years now.

This 4way handshake issue I currently have, I have had on Mikrotik devices since I tried to connect the first apple device to an AP (oh and a lenovo laptop that simply does not work on Mikrotik wireless till today). This was years ago when Routerboard just started building "all-in-one" RBs where APs were built into RBs. Brilliant idea though

We get new toys and new features with new ROS versions, but very so often devices and features that has issues; simply never gets resolved. Has been like this since ROS 4.0...

R

Hi,

can you try the following anderen see whether this helps for you:

/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan2

/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan1

/interface wireless set amsdu-limit=4096 amsdu-threshold=4096 mode=ap-bridge wps-mode=disabled wlan2

/interface wireless set amsdu-limit=4096 amsdu-threshold=4096 mode=ap-bridge wps-mode=disabled wlan1

/interface wireless set wireless-protocol=802.11 wlan2

/interface wireless set wireless-protocol=802.11 wlan1

/interface wireless set wmm-support=enabled wlan2

/interface wireless set wmm-support=enabled wlan1

After that enable CAPSMAN Mode with group key Timer Set to 5 minutes

Hi,

can you try the following anderen see whether this helps for you:

/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan2
/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan1
/interface wireless set amsdu-limit=4096 amsdu-threshold=4096 mode=ap-bridge wps-mode=disabled wlan2
/interface wireless set amsdu-limit=4096 amsdu-threshold=4096 mode=ap-bridge wps-mode=disabled wlan1
/interface wireless set wireless-protocol=802.11 wlan2
/interface wireless set wireless-protocol=802.11 wlan1
/interface wireless set wmm-support=enabled wlan2
/interface wireless set wmm-support=enabled wlan1

After that enable CAPSMAN Mode with group key Timer Set to 5 minutes

Hi there,

Thank you for the advise. Bear in mind that in non-local forwarding mode CAPsMAN sets everything on the interface. Even if you try to set something and then enable CAPsMAN, it overwrites the settings as per its configuration. The only way I could get that to work (the settings to stick) was to enable local forwarding mode. Now the virtual interfaces do not go into their VLAN bridges and removes themselves every day. So I have to log in to every router every day to re-add the virtual interfaces into the correct bridge.

Strange that that does happen though....

Think you might need to "get your VLAN Tags" on the proper interface. Then bridged to the right interfaces.

Think you might need to "get your VLAN Tags" on the proper interface. Then bridged to the right interfaces.

Define "proper" please?
I think we may be speaking past each other. The virtual APs (wlan161/162/163/164) changes name every day for what reason I would love to know. Nothing switches off, nothing reboots. Yet every day those virtual APs will have different interface names and therefor no longer be part of the correct VLAN, in the bridge > port screen I only have "unknown"s.

If you are running this as CAPS-MAN... we would need to see the config of the Caps-Man on the router. Set the APs to local forwaring.

If you are running this as CAPS-MAN... we would need to see the config of the Caps-Man on the router. Set the APs to local forwaring.

As I mentioned in previous comments, a virtual AP is disabled when CAPsMAN does the forwarding, this runs on a UDP stream in the background. If local forwarding is enabled, the interfaces becomes enabled. You cannot add a disabled interface to a bridge???

You still did not elaborate as to what you deem as "proper" vlan setup?

RaynoP: I'd try 6.40.8 if it weren't for the cAPs ac, which were very recently released and require current branch (see changelog).

I'd put the blame on them... thing's I'd try:

- Check that System > Routerboard Upgrade Firmware matches Current Firmware, upgrading if it doesn't (all devices).
- netinstall all of them with 6.42.5 (or reset them to no defaults)
- Just to isolate: Try more mature, different Ap models, wAP ac's for example.
- Try 6.40.8 on the RB3011

Have multiple installs with RB3011 as border router + CAPs Manager with wAP acs, Hap ac, Hap ac lite, RB951... working fine. (bugfix on all)

If you are running this as CAPS-MAN... we would need to see the config of the Caps-Man on the router. Set the APs to local forwaring.

Here at the office I have a CCR1009 running as the router. Currently a cAP AC as the wireless.

Using local forwarding and VLANS configured on the interface of the CCR and bridges... there are 3 subnets.
1. Office network.
2. Guest network.
3. EoIP network to another site.

These are all VLAN tagged in the caps-man config.
So the CAP itself doesn't have much setting on it.

i think is better to try first this setup without capsman

then

validate its working

then

migrate to capsman (using local (access-point) forwarding)

in that way you keep problem resolution simple and discard or confirm easy if some issue is related to campsman

bonus track

you can easily move one AP to stand alone mode (without capsman) for testing, keeping it in the schema

RaynoP: I'd try 6.40.8 if it weren't for the cAPs ac, which were very recently released and require current branch (see changelog).

I'd put the blame on them... thing's I'd try:

- Check that System > Routerboard Upgrade Firmware matches Current Firmware, upgrading if it doesn't (all devices).
- netinstall all of them with 6.42.5 (or reset them to no defaults)
- Just to isolate: Try more mature, different Ap models, wAP ac's for example.
- Try 6.40.8 on the RB3011

Have multiple installs with RB3011 as border router + CAPs Manager with wAP acs, Hap ac, Hap ac lite, RB951... working fine. (bugfix on all)

Thank you for the reply. These are the only ceiling mount AC APs (RBcAPGi-5acD2nD) I can get my hands on. All the others are desktop.

I generally don't NetInstall a RB unless it is required and being brand new out the box APs, which were factory loaded with ROS 6.41, and is literally in a vanilla setup, I tend to disagree that older ROS versions works better than newer (depending on what changed of course hehe). And to be honest this interface removal out of bridge setup is something I had on ROS since CAPsMAN v1.

Don't misunderstand, everything WORKS. But, as soon as we have 40+ devices per AP and old 2.4GHz devices mixed with new, I get the 4way handshake issue. The heavy disconnection of devices were resolved when I switched over to local forwarding. So over and above the 2.4GHz radio not being able to handle multiple types of old and new 2,4 GHz radios, the virtual APs removes themselves from the bridges.

Here at the office I have a CCR1009 running as the router. Currently a cAP AC as the wireless.

Using local forwarding and VLANS configured on the interface of the CCR and bridges... there are 3 subnets.
1. Office network.
2. Guest network.
3. EoIP network to another site.

These are all VLAN tagged in the caps-man config.
So the CAP itself doesn't have much setting on it.

I tried setting the vlan tagging on the CAPsMAN config. The devices simply does not get DHCP addresses.

My setup is very similar to yours

When you set VLAN tags on the SSIDs and have local forwarding enabled... you don't get an IP from the router?

If you configured everything right on the router... that usually means you have a switch stripping off the VLAN Tags.

Your exported config using caps-forwarding will skip right through VLAN aware switches.

i think is better to try first this setup without capsman

then

validate its working

then

migrate to capsman (using local (access-point) forwarding)

in that way you keep problem resolution simple and discard or confirm easy if some issue is related to campsman

bonus track

you can easily move one AP to stand alone mode (without capsman) for testing, keeping it in the schema

Again, read my posts from beginning to end. You will see that I have tried all you suggested, problems persists.

I think it is a compounded issue. Maybe the cAP AC APs cannot talk to old 2.4 radios (older than 3 years) and maybe CAPsMAN or the APs cannot handle 40 devices of all sorts and manufacturers at once. Maybe CAPsMAN does not know how to tell the AP not to remove virtual interfaces to not "break" bridged configs?

I also tried setting datapaths, which is supposed to add the AP to the bridge specified. Problem then is, you can only run one SSID as the virtual APs do not know to which bridge they should be added. The more obvious solution would be then to specify a VLAN (use tag) config. This "works", but DHCP does not work and the devices jumps onto any VLAN they want to.

I think I have gremlans

When you set VLAN tags on the SSIDs and have local forwarding enabled... you don't get an IP from the router?

If you configured everything right on the router... that usually means you have a switch stripping off the VLAN Tags.

Your exported config using caps-forwarding will skip right through VLAN aware switches.

I thought the same thing. Initially the setup was: 3011 > CRS328 > RB960 (power box) > cAPs. The CRS328 is an absolute nightmare to setup on VLANs (second CRS I bought and last one!!!!). I watched MUM video after MUM video (both Japan and UK) recently held to enable me to use the new "bridge VLAN setup" opposed to the old switch menu config.

Sooo, because of this I then plugged the RB960 directly into the 3011. Everything works, except the one or two issues at hand. Personally I prefer the vlan tagging to be a virtual interface, but I think they "new" way may be better in the long run

RaynoP: I'd try 6.40.8 if it weren't for the cAPs ac, which were very recently released and require current branch (see changelog).

I'd put the blame on them... thing's I'd try:

- Check that System > Routerboard Upgrade Firmware matches Current Firmware, upgrading if it doesn't (all devices).
- netinstall all of them with 6.42.5 (or reset them to no defaults)
- Just to isolate: Try more mature, different Ap models, wAP ac's for example.
- Try 6.40.8 on the RB3011

Have multiple installs with RB3011 as border router + CAPs Manager with wAP acs, Hap ac, Hap ac lite, RB951... working fine. (bugfix on all)

Maybe I should remove the 2.4GHz config on the cAPs and add hAP AC Lite RBs to the mix for only 2.4GHz?

Pfft, "newbie". Been using MK since version 3.17 over almost all major hardware versions, Hahahaha

I noticed a CONSIDERABLE increase in stability and speed when I switched to local forwarding and VLANS on Mikrotik wireless

Also using VLAN tags lets me change brands and deal with things like phones plugged into non core switches.
Tik WAPs don't get close to the throughput I get out of Ruckus WAPs. But at 1/10th the price... you have to make some exceptions.

I just found a common anomoly! Some keep alive timeout temd-out and then the picture happened. So we know now what is removing the devices from the bridges. We now just need to figure out why?

See attached please

I noticed a CONSIDERABLE increase in stability and speed when I switched to local forwarding and VLANS on Mikrotik wireless

Also using VLAN tags lets me change brands and deal with things like phones plugged into non core switches.
Tik WAPs don't get close to the throughput I get out of Ruckus WAPs. But at 1/10th the price... you have to make some exceptions.

I wish I could get proper Ruckus devices! However, if MikroTik addresses issues pertaining to systems that users mention here, we would not have these issues. From the very first 2.4GHz wifi AP I installed many moons ago, initially I had iPhone connection issues, then this then that. My wife's Lenovo laptop refuses to work with any MikroTik 2.4 GHz AP. Why can ubiquity get it right? Not trying to shake the hornets nest, but one AP from theirs works with any device and huge device densities....

Ubiquiti and device density was PRECISELY why I moved to Ruckus.

I watched those UniFi WAPs crumble under loads and flat out give up in noisy environments.

Ubiquiti and device density was PRECISELY why I moved to Ruckus.

I watched those UniFi WAPs crumble under loads and flat out give up in noisy environments.

Wow, we had the total opposite. One UniFi LR on both bands. Kicking 4 (soon to be 5) cAPs to the moon and back

I have not had the opportunity to put a CAP AC under high load yet. I have lots of "eyes on" seeing UniFi radios get over run. My Ruckus installs have had the DHCP-Server give up before the radios did.

I have a hAP AC2 at home running with 30 devices connected. So still trying to find its "Break Point".

I have not had the opportunity to put a CAP AC under high load yet. I have lots of "eyes on" seeing UniFi radios get over run. My Ruckus installs have had the DHCP-Server give up before the radios did.

I have a hAP AC2 at home running with 30 devices connected. So still trying to find its "Break Point".

Try different vendor devices. Oh, also add 48 badly setup Unifi radios TX on max power on all freq with max channel width. The people above us believes to install 48 APs in a 200m2 office area is awesome...

MikroTik Support: I don't know if you read these forums, but I think the problem is in the refresh of the Certs. Every now and then the APs do a refresh on the Certs from CAPsMAN. As soon as that happens everything disconnects for a couple of seconds. The log then shows something about cert refresh and then I have to wait for 5.8 radar detect ti finish. Once done I can add the devices back into the bridges.

As for trying different devices...
Android phones from Google and Samsung.
Wii
Playstation
Xbox
Roku
LG OLED
Panasonic IP camera from 10+ years ago.
iPhones
iPads
Chromecast + Chromecast Ultra
Acer laptop
Samsung Chromebook
Lenox thermostat.
Oppo Blu-Ray
Etc etc

The one thing that seems to show "disconnect messages" is a Digital Loggers Web power switch.

As for trying different devices...
Android phones from Google and Samsung.
Wii
Playstation
Xbox
Roku
LG OLED
Panasonic IP camera from 10+ years ago.
iPhones
iPads
Chromecast + Chromecast Ultra
Acer laptop
Samsung Chromebook
Lenox thermostat.
Oppo Blu-Ray
Etc etc

The one thing that seems to show "disconnect messages" is a Digital Loggers Web power switch.

Ahhh, you just need about 40 more

Like I posted... it's carrying about 30 devices on average.

Had a bar "go cheap on me" recently. They bought their own UniFi waps. Location would have been perfect for 2 cAP ACs.
4 days after deployment... they have had a maximum of 14 clients on the wireless at once.

Like I posted... it's carrying about 30 devices on average.

Had a bar "go cheap on me" recently. They bought their own UniFi waps. Location would have been perfect for 2 cAP ACs.
4 days after deployment... they have had a maximum of 14 clients on the wireless at once.

All of that in your home, wow ok - don't need electricity to cook something LOL. I moved the CAPs setup over to the RB960 powerbox and had to install an additional cAP on the second port of the fourth cAP.

Previous setup:

• RB3011(CAPsMAN, DHCP for all vlans, wired and wireless, and the edge router) > RB960 > 4 cAPs, one per port on the 960

New setup:

• RB3011(DHCP only for wired vlans and the edge router) > RB960(CAPsMAN, DHCP for the wireless vlans) > 4 cAPs, one per port on the 960. The additional cAP (no 5) is connected to port 2 of the fourth cAP. This is pushing the 960 a little close to its max port power output and thus the ether begins to flap or the cable got damaged as the bend radius is stupendously tight for an RJ45 to be inserted

Steps taken more or less from beginning to end:

• Initially I had the RB960 setup as a L2 switch (bridged all ports) - primary idea for it was to simply be a power source and to prevent the additional cabling of 4 APs (but also have the power of another RB should the need arise). As ether3 on the 3011 was bridged into the management vlan, I had all management IPs of the APs on their ether1 or bridge

• Then I removed the "all interface bridge" and added vlans to every port - management IP on ether as before. They were bridged each in their own bridge - no IPs

• I added a dedicated management vlan to all devices with local loopback bridges assigned to it; as I thought that maybe the 3011 and its CAPsMAN got confused between the physical interfaces and the bridges (I know it sounds silly, was eliminating everything that could possibly be a problem)

Finally problem disappeared:

• Removed the bridge that were on all interfaces on the 960. Now, only the vlans, are bridged and had to get IPs in order for the local DHCP to run. Now the APs don't lose communication to their controlling CAPsMAN and the vAPs remain in their bridges. BUT - if you change anything on the CAPsMAN setup you have to re-add the vAPs - the inevitable was simply postponed, not fixed

• I'll have to write a script on a schedule of every 5 minutes or so, to automatically add the vAPs - something CAPsMAN should do

I am curious as to why this setup is more stable than the previous one? Nothing much has changed ito the core setup and base packet flow. Initially, after upgrading to ROS 6.42.5, CAPsMAN were able to add the vAPs back into their bridges on the cAPs, but it lasted for 2, maybe 3 disconnects before that stopped working??!??!!
I am also unable to ping the DHCP IPs on the RB960 from other VLANs. Surely I don't need additional route than the default (0.0.0.0/0)? What makes this even more curious is the management vlan works perfectly, but the other vlans not. Nope, no firewall rules at all.

"I'll have to write a script on a schedule of every 5 minutes or so, to automatically add the vAPs - something CAPsMAN should do"

Creation Dynamic???

And as for my home. I intentionally put everything on WiFi so I can to produce a "WORSE CASE" situation.
Would never allow this in my production networks... but I have reference right here when I need it.