Good morning everyone, until a few weeks ago, I had the RB3011UiAS-RM routerboard running version ROS6.48, which was used as the capsman for all the CAPs (wAP-AC) (also running version 6.48) managed and operating with multiple SSIDs and different network subnets (CORP1-CORP2-GUEST, etc.).
The company decided to add APs but purchased the latest ones (wAP-AX), which clearly don't work with the old capsman…..
Before destroying the old capsman, I took another RB3011UiAS-RM from the warehouse and imported my routerboard's configuration. To make sure it worked, I physically replaced the old one, and everything worked fine.
At this point, on the old RB3011, I only changed the LAN IP from (192.168.10.2 to 192.168.10.5) to make them coexist on the same subnet, and then I updated it to version 7.20.
I then took one of the old APs and changed its Capsman IP to the new IP (192.168.10.5), and it works exactly as before! So far, so good.
I followed a few tutorials to connect the new wAP-AX to the new caspman, and it works. The SSIDs are displayed by the AP and managed by capsman, but when I try to connect with a device, it doesn't even receive DHCP because it doesn't seem to communicate with the 192.168.10.0/24 subnet where the DHCP server is located. However, if I connect directly to the AP, I can ping all the devices on the subnet (both the GW and the DHCP server).
My question is: what could be different about the Wi-Fi configuration that works on a device running 6.48, but no longer works on 7.20?
I don't use VLANs, just bridges to distinguish the subnets the client should participate in based on the SSID it connects to.
Thanks!
If you need it, I can also send you the configuration files for the various devices. Thanks to anyone who can answer!
But I think one cause of this could be that cAP ax is missing the datapath settings. Does it have the bridge datapath configuration shown in this example?
I'm not sure how one should interpret settings /interface/wifi/datapath bridge on both CAPsMAN and CAP ... but in certain interpretation bridge named in mentiobed setting would have to exist on CAP (for traffic handling), but in your case it doesn't.
/interface/bridge/port/print
Flags: I - INACTIVE; D - DYNAMIC
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID, FRAME-TYPES
# INTERFACE BRIDGE HW HORIZON TRUSTED FAST-LEAVE BPDU-GUARD EDGE POINT-TO-POINT PVID FRAME-TYPES
0 ether1 bridge1 yes none no no no auto auto 1 admit-all
1 I ether2 bridge1 yes none no no no auto auto 1 admit-all
2 D wifi1 bridge1 none no no no auto no 1 admit-all
3 D wifi2 bridge1 none no no no auto no 1 admit-all
I tried disabling the wireless packet on Capsman to see if the old AP configuration was causing the issue, but it didn't change anything at all.
I can see the Wi-Fi network on the new AP (which means the connection between Cap and Capsman is working). It lets me connect, but it doesn't get an IP address because the DHCP server for the 192.168.10.0/24 network is 192.168.10.20, which I can't reach from the connected client while it's being pinged by the AP (Cap).
You seem to have gaps in your knowledge of computer networks.
A device located on the 192.168.100.0/28 network belonging to the bridge-management bridge will never be able to connect to a DHCP server operating on the 192.168.10.0/24 network on the bridge-CORP bridge.
Set up a separate DHCP server on the bridge-management bridge and your devices will receive IP addresses.
You need to use VLAN.
I haven’t used the older /caps-man, so please correct me if I’m wrong .local-forwarding=no in the older config tells the cAP to direct traffic to the CAPsMAN for forwarding between networks/ssids, right? The CAPsMAN receives wifi client traffic on the management LAN and forwards it out to the various bridges on the CAPsMAN server.
If you are trying to do that on v7.20.x with the new CAPsMAN with ax devices on the wifi-qcom driver it won’t work. Only local forwarding is currently supported, per the info on Datapath at that page. With the new driver/CAPsMAN the cAP can’t send the forwarding traffic to the CAPsMAN - it can only do local forwarding. This changes in 7.21 and it should be supported.