Hi

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.

Any ideas ?

Thanks
Yann

setting the bridge to use its manually added mac address should solve the problem.
Where is the problem?

Thanks for your response Uldis

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

Thanks for your response Uldis

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).

Thanks for your response

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 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

This installation is for a hotel, therefore I dont think that enabling local forwarding would make any sense

This installation is for a hotel, therefore I dont think that enabling local forwarding would make any sense

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.

Thanks again for your responses

I must be unaware, or rather ignorant, of the uses of local forwarding

I thought that since what clients require is Internet access, and not client to client exchanges, then local forwarding would not be necessary

The switches used for these small installations are RB260GSP

yann

Thanks to Martin, from support, for pointing out a parameter I was unaware of:

when you configure the admin-mac address for a bridge, you also have to disable the auto-mac feature for the address to be properly taken into account

Now I can add the wlan1 interface to the bridge without any issues