In the beginning the devices broke down once I updated them to 6.32.4: then after much trial and error they accepted an update via Netinstall to ROS 6.35
Then they wouldn’t play nice in auto channel mode within Capsman : so I provisionned them with the desired wireless specifications
Now the bridge is the problem
On each I have bridged ether1 and wlan1 and assigned an IP to bridge1 and set STP to none
Upon reboot, or even sometimes later, wlan1 becomes the designated port and the bridge adopts wlan1’s MAC address.
So I remove the bridge and ports and start all over again; but to no avail since this will happen again
I tried with RSTP enabled but got the same result
I gave the bridges their own admin MAC addresses: no improvement
The RB912 which have been configured in the same manner are behaving properly on this same network
It seems hard to believe that I’m the only one having this many issues with the wAP devices.
On the wAPs the bridge systematically ends up using wlan1’s MAC address.
I did try to set the bridge’s admin MAC address but as with the wireless’ MAC address, the interface isn’t reachable via layer 3.
I don’t understand why it works at the moment, that is, by not adding wlan1 to the bridge, but indicating bridge1 in the wireless’ CAP settings
That is the only way I have managed to get it to function properly.
I have either received a bad batch, or else it is just me doing it all wrong; I have however never come across these types of issues with other Routerboards
If you are running the wAP as a Capsman AP you should not put wlan1 into the bridge - Capsman will dynamically add them if required (assumes local forwarding is being used).
Local forwarding has been disabled in the CAPsMAN settings, for all APs
All RB912 on the same network are configured with a bridge containing both ether1 and wlan1, and they are functionning quite nicely; it is only the wAPs that seem to have a problem with this setup
Lastly, I don’t see the purpose in creating a bridge that will contain a single interface
Local forwarding is way faster than using DTLS transport - less cpu utilisation. See posts regarding hAP AC Caps Performance without local forward.
In the /interfaces wireless cap config you need to specify a bridge for local forwarding so the wlan’s can be dynaically attached - hence you need one.
If you are not using local forwarding then you don’t need a bridge at all. I would not be putting wlan1 in a bridge statically if I were using capsman - INMHO
We use these in hotels with local forwarding. If you use managed switches then it shouldn’t be an issue and you can use VLAN’s if necessary for isolation.