Hello,

I recently got a few of the Audience devices and I'd like to reconfigure them to use external CAPsMAN, while also having most of them working wireless-only / as part of a mesh network.
I'm trying to set up a network with single CAPsMAN, managing Audience APs in mesh mode (one unit with Ethernet backhaul, rest wireless-only), plus a few cAP AC units with Ethernet backhaul.
RB5009 would be used as a router, firewall and CAPsMAN.

The default behavior of the Audience devices is that they'd first need to get the config from the primary Audience unit, then they'd be able to operate fully wireless and the config would persists across reboots.

So far, I managed to copy the CAPsMAN config to RB5009 and I can get the Audience units to grab the config when connected to the Ethernet, but they don't seem retain it and are unable to connect to the mesh when running wireless only.

I'm not sure what's the proper / optimal way to go about this.
According to the CAPsMAN docs, I can define interfaces as either dynamic or static.
All the online CAPsMAN config guides used create-dynamic-enabled in provisioning rules. Would using create-enabled to provision static interfaces solve the issue of config loss on reboot?
Or is there a better way to do this?

CAPsMAN doesn't configure backhaul ... which in usual AP installation is ethernet while in mesh it's the 4x4 radio (I guess it's called wlan2 when running wireless drivers, it's wifi2 when running wifi-qcom-ac drivers). Further more, radios loose their setup if they loose connectivity towards CAPsMAN device (there are reasons to believe this is actually a feature).

So what you can do is to keep using first Audience to set-up mesh and only use CAPsMAN to provision 2.4GHz radio and the 2x2 5GHz radio. Butvery likely you'll have to fiddle with config on all meshed Audiences manually to make it work.

BTW, if your Audiences are still running wireless driver, then moving CAPsMAN to RB5009 means waste of resources, you'd have to install wireless package and that device doesn't have radio. So apart from central management you wouldn't gain anything.
If OTOH your Audiences are running wifi drivers, then nothing special has to be installed on RB5009.

Thank you for the explanation, I think I now have a slightly better understanding of what's going on.

The main idea behind setting up CAPsMAN on RB5009 was to have one central config management for a mixture of Audience and cAP AC units.
I don't want to use CAPsMAN on Audience, as there's higher chance of those units being damaged / replaced than the RB5009.

I dug into the setup scripts for Audience, and it seems like they use wlan1 and wlan2 with CAP, while wlan3 is WPS-Sync repeater.
Wlan2 and wlan3 share the SSID, but use different security profiles, while wlan1 shares the security profile with wlan2.
They don't use any configuration from the actual Mesh section, all seems to be done as generic interface config.

I can't use Audience devices in the default Home Mesh mode, as that configures each unit to act as a router and I'd rather leave all routing to RB5009.
On the other hand, setting up those devices via CAPsMAN with backhaul seems difficult and could complicate the overall deployment.

Considering all this, and the relatively low number of Audience units I have, it seems to me that it may be easier to use static config for the Audience devices, while using CAPsMAN for cAP devices only.

Using CAPsMAN to provision audiences' "public radios" (i.e. the ones serving normal client devices) gives opportunity of better client mobility ... APs, participating in client mobility, have to be controlled by single entity (e.g. CAPsMAN) for all the mobility features (802.11 r/k/v) to work as intended.

I can't give any concrete advice about what needs to be done manually before CAPsMAN can do the rest of the job, I only have a single Audience, so no mesh.

Thank you for pointing out the mobility considerations, I didn't think this through properly.
I managed to create a hybrid config with wifi1 and 2 on CAPsMAN, while wifi3 is configured manually for backhaul, but the it's not working too well.
I created a separate thread in the Wireless Networking section for this - viewtopic.php?t=213439