I know this has been discussed before but I didn’t see any kind of resolution.
When using CNUT to change firmware versions in radios, SM AutoUpdate does not work. I have had this issue with more than one AP at more than site. When I telnet in and issue the update command, I get the message that
|Autoupdate currently Disabled|
Currently, most of my SMs have NAT turned on and I do not have the Radio Public IP active as I access them via the APs LUID. Does anyone know of a work-around or solution other than configuring the SMs Radio Public IP and putting on the network? That requires too many reboots for my commercial customers to deal with
Thanks in advnace.
post your AP config on here…do you have the autp update IP set on the AP?
When we finally upgraded everything to advantage? we had to use the older version of Cnut. to upgrade our sm’s to 7.3.6 hws.
The new version did fine on the Cyclones, but wouldn’t even reconize the sm units.
after the upgrade the only problem, We had a few of the p-8’s that didn’t work correctly after the upgrade.
does anyone know how to use telnet to upload the file and then initiate the auto-update?
i dont think you can after 4.2.3
Yah, I have no problem getting CNUT to see the SMs and list them after and AutoDetect. The issue is not in the SMs or even CNUT - it is the APs that are not cooperating. With CNUT I can use the tool to enable AutoUpdate on an AP, and it will check the status, and transfer the files to the AP. When it tries to enable AutoUpdate it says no SNMP response. When I manually enter the update command in Telnet, the AP says “Screw You, I won’t let you do that”. :lol:
Also I’m not sure what in the AP configuration would affect the AutoUpdate. And the Update Application Address in the AP doesn’t seem to make any difference.
My destktop has public IP. The autoupdate address is the IP of my PC. CNUT 2.2. SMs have private IPs, but this is not importend becouse if I update only the APs the SMs will autoupdate. I have tryed this on two clusters with 8.1, no problems.
My PC and my APs are one the same logical subnet, within the same VLAN - no routing between them, all private IPs.
the update IP for the AP config should be the IP of the machine with cnut on it. It should be on the same range as all of you AP’s
I believe there are two ways of doing it. #1 is to have that machine host the files #2 is to have the AP host the files. im not sure if there are any benifits of either one.
if you are having an snmp error make sure the snmp string on cnut and the AP config page match. also make sure the AP has the update IP of your cnut box
Yup, the update IP does not make a difference - with or without it I get the same message from the AP. There is no issue with SNMP or addressing - I can access and update the AP with no issues. :?
We had to use the older version Cnut, to correct this issue. Don’t know why but it worked.
Hmmm… interesting. I’ll install it on another machine, try it, and let you know…
Does anyone know where to get CNUT 1.1?
I am trying to update to 7.3.6, and have had similaar troubles with the atuo update.
Is there any other way around this, without changing all SM IP’s to public?
I was told you could get it from canopy support. I have a copy but not smart enough to send it.
I have just found it, i will install it and give that a try.
CNUT 1.1 did not make any difference. It still seems to be an issue with the radios and not CNUT as I can get AutoAupdate on in other APs without issue.