Hello, hopefully ive included the right amount of information. I’m experiencing an issue with my Cambium e500 cnPilot radio and would appreciate some assistance. Here is the setup:
Two SSIDs: “Free Hotspot” (VLAN 50) and “VIP Hotspot” (VLAN 100)
VLANs: Both VLANs are tagged on the WLAN page
Ethernet Port: Configured as a trunk port, allowing VLAN 50 and VLAN 100
Router: Mikrotik router connected to the radio on eth5, with VLAN 50 and VLAN 100 installed on eth5
VLAN 50: Bridged to an EoIP tunnel to another router managing DHCP and queuing
VLAN 100: IP range 192.168.100.1/24 installed on VLAN 100
Management Bridge: eth5 is in a mgmt_bridge giving DHCP to all NICs but not to the VLANs, with IP range 192.168.15.1/24 for management
Everything works fine most of the time, but occasionally, devices connecting to the AP get allocated to VLAN 1, even though there are no SSIDs with VLAN 1 being broadcast. These devices end up receiving IP addresses from both the management DHCP and the DHCP server on the router connected via the EoIP tunnel.
Question: Why are some devices randomly allocated to VLAN 1 when there are no SSIDs with VLAN 1 being broadcast on the AP?
Additional Info:
Mikrotik router is running the latest stable long-term firmware
APs have consistently shown this issue across various firmware versions and are now on the latest firmware from Cambium
Any insights or suggestions would be greatly appreciated.
I haven’t touched e5xx in several years, but have seen this behavior on newer models. I am assuming you are using cnMaestro for management -
Enterprise cnPilot devices have a default/hardcoded fallback IP of 192.168.0.1 (which does NOT show up in a device configuration export via cnMaestro) - even if NO ports are explicitly configured to have membership in VLAN1.
Because this fallback IP is hardcoded by default, the AP’s internal ebtables/iptables will install a locally connected route for 192.168.0.0 on the untagged/native ethernet uplink…
If your utilized networks fall within the 192.168.0.0 range, the routing table sometimes might accidently ‘leak’ some of the traffic untagged out the ethernet port - even if device is connected to a SSID associated with a different VLAN.
If you have LLDP enabled in your environment, your Mikrotik should be able to see the radio’s 192.168.0.1 fallback from its neighbor discovery on ether5.
cnMaestro gives no means of disabling the hardcoded fallback IP, and additionally hides the ability to remove VLAN1.
We tried to use a 10.1.1.0 range to see if that helped us out by moving away from the 192.168.0.0 range however it didnt help.
We have looked over the fixes that you provided and have decided at this point not to implement a workaround. Cambium have asked us to open a support ticket which we have done, ill update this post once they come back with something.
Final update to this - we opened a support ticket with Cambium and they have been working on the issue. It appears that there was another AP in the area broadcasting the same SSID on VLAN1 and then the client has roamed to our AP with the SSID on a different VLAN which was causing the issues. Cambium say that this is normal and to solve it, make all APs in the area broadcast the same SSID / VLAN instead of having different VLAN at each AP.
