We are testing AAA authentication with PEAP on one of our new APs (CBRS 3 GHz). It is working fine, but when we have the atttribute Cambium-Canopy-VLMGVID set to assign the vlan mgmt ID, cnArcher hangs after the sm initially connects, and fails to finish the setup. It works fine if we don't pass the mgmt vlan.
Are there best practices with using RADIUS attributes when using cnArcher?
cnArcher uses the "default alternate LAN1 IP" of 169.254.1.1 to communiate with the SM. Even when the SM management IP is changed via RADIUS based IP assignment, it should not impact the ability of cnArcher to continue talking to the SM on 169.154.1.1 but it looks like we may have a bug here.
Can you please send use the debug logs using "Report a bug" menu item? We will also look into this in parallel.
Hey there, I work with "Arakasi" who started this thread.
First of all to what email would you like the bug report from cnArcher sent?
In my experience, once the SM gets it's MGMT VLAN set, and subsequently grabs a DHCP MGMT IP, cnArcher is only able to communicate to the SM briefly immediatly after a power cycle of the SM; once it registers with the AP and gets DHCP, cnArcher is no longer able to see the SM (doesn't respond at 169.254.1.1 at all). Which is normally OK if you set the MGMT VLAN through cnArcher itself, as it is one of the last steps it asks for.
Attached is the screen cnArcher gets to and hangs at when the MGMT vlan is sent through RADIUS.
Also attached is the cnArcher_logs.txt file from my phone, I cleaned out the old logs up to the point where we turned on this setting in RADIUS and the problem started.
So there is probably a couple failed attempts, when RADIUS was pushing out MGMT VLAN, and then a successful one where we disabled that option in RADIUS.
I am not able to access the screenshot or log files attached here. Please send it to cnarcher@cambiumnetworks.com.
Strange, I can access them from the post....
Attachments sent to that email, and referencing this forum post.
Also if it helps, I have an SM on my own roof that we can use to do any kind of test you like regarding this.
We are able to recreate this issue. When SM gets an IP from RADIUS server, it starts responding to SNMP requests from the app using the assigned IP istead of 169.254.1.1. Since the app is making SNMP requests to 169.254.1.1 and getting response back from a different IP, the SNMP library used by the app is not able to match the response to the request.
We are investigating options to fix this.
I too am curious to follow this issue. We have the same problem stopping us from rolling out with cnArcher.
The fix is on the radio side, and it is included in version 16.2.1 (Beta-4). You can download the beta from https://support.cambiumnetworks.com/files/pmp450/beta or it is also available for download in cnArcher itself.
Please try with this version loaded on the SM and confirm that this fixes the issue.
Hey there, we tested this again on 16.2.1 Beta-4, and are still getting the same results; as soon as the SM attaches to the AP, it get's pushed it's managment VLAN from RADIUS, and presumably get's a DHCP IP address, cnArcher can no longer communicate to the SM.
@jameth, We are facing some delays getting an end to end setup working at the house of the engineer that needs to debug this scenario. This is due to travel and office access restrictions in place. But we are working towards it.
--Rajesh
Please try out the latest cnArcher (Beta) 1.6.4 build.
If you are not currently a beta tester, scroll down to the bottom of the cnArcher Play Store page and click “Become a Beta Tester”. This can only be done from the Play Store on your phone, and not from a browser.
