320 AP Unmanageable via CNUT for Upgrade


I have a 320 AP on a route-able IP @ Cascade. When I try to manage the device via CNUT, it fails to respond and therefore can not be upgraded. The customer has actually gone out to the AP this morning and tried connecting directly to the AP and the device is still not responding to CNUT. I have verified the user name and password via the web interface, and I am using the default SNMP community string "admin_admin". Is there anyone that can help? Please feel free to contact me directly.

Submitted by Pranav Joshi on May 04, 2019 Permalink

Just some clarifications to the Paul's last post. For PMP320 AP, SNMP community string please use _ So, if you are using default username/password it will be admin_admin If user create a new account e.g. XYZcorp with password of XYZaccess with admin privilege, community string could be used as XYZcorp_XYZaccess. We were able to discover the AP using CNUT with our FTN network without any problem. On the same token, we are not able to do the same using our Motorola network which may be blocked by proxy.


Based on our test using the correct community string CNUT able to discover the PMP320AP without any problem, confirmed with Paul and his AP has been upgraded without any problem.


The subnet mask is the known issue with the old factory load (rel3.1_B20146). The latest AP SW (B23400) with release e.1.0.1 fixes the problem.




Submitted by Paul Vallesteros on May 04, 2019 Permalink

FYI: In speaking with Pranav I have found that the documentation is NOT CORRECT for the SNMP community string. The string is "admin_password", vs "admin_admin". Also, the version of code that these demo units ship with may have a problem with a \30 subnet mask. Waiting on Pranav to get back to me with his findings.