I’m trying to use CNUT to update some SMs and APs and keep getting the same error:
DeviceStatus=Status:-1;HOST:10.1.4.151;ESN:0XXXXXXXXXXX;Message:File Transfer Error: Connection, File Space or Permissions Error ( SITE= XXXXX)
I have tried using Passive FTP with the same results.
All these devices are in a remote location and I’m accessing them through an IPSec tunnel. I’m running CNUT on computer on a different subnet.
Computer (192.168.0.X) - SonicWall - IPSec Tunnel - Linux Box - IPSec Tunnel - IPSec Endpoint - APs and SMs (10.1.4.X)
As far as I know, the upgrade process is done using FTP and Telnet, so the APs and SMs not being able to contact the CNUT computer should not matter.
I can FTP, Telnet and browse into all devices without a problem.
Is CNUT doing something differently that can cause this problem when going through different routers and an IPSec tunnel?
Thanks for the help!
Are the units under heavy load?
I have 3 SMs and at least two of them I know are not under heavy load (or even any load at all) at the time I’m attemtping the upgrade. They might get some traffic but nothing major.
I sniffed the traffic being generated by CNUT whily trying the upgrade on the AP and I see a couple of things that caught my eye.
CNUT does a telnet session first and obtains MAC address, and Versions. It then opens a regular FTP session and does the following:
BITMAP.SYS: is a directory
FLST.SYS: is a directory
DELE Command Successful
The first two commands fail but the third one works. Then another FTP connection is opened, passive mode is enabled and CNUT starts uploading APboot.bin.
I can see the FTP data being transferred and completed. But after the last TCP packet is acknowledged by the SM, I never see another packet to or from the AP’s IP.
Could it be that CNUT is timing out? Expecting the transfer to be done in less time than what it is actually taking? That wouldn’t make much sense.
If I FTP into the AP after the update failed, I can see the APboot.bin file on there with the correct size and today’s date and time.
Well it turns out that when I try to upload the SMboot.bin file to the SM using a regular FTP client, the connection is terminated after the same amount of bytes is transmitted every time. For the AP that number is 1,000 kbytes. For the SM it’s around 980kb. It’s strange, it always happens at the exact same place.
I’ve uploaded several files that add up to more than those amounts with no problem, so it’s not a space issue.
I have no clue what’s going on.
Try to reboot the unit prior the upgrade. Sometimes it can help. Let me know.
Thanks for the tip marwill, but that didn’t work.
I did one more test. If I telnet into the SM, and then FTP into my server and downlod the file INTO the SM, the file is transferred without any errors.
Problem is I don’t think I’d feel very comfortable doing the upgrade manually and want to use CNUT to reduce the chances of anything going wrong.
I might try setting up a TFTP server and doing the AP upgrade thing.
I tried using the autoupdate through a TFTP server and that didn’t work either. I was able to enable the Autoupdate mode on the AP and then I could see the SMs trying to get the files off the TFTP server only to have them timeout immediately:
Timeout error sending SMboot.bin from XX.XX.XX.XX, 0 bytes
Transmit error while sending to XX.XX.XX.XX : The connection is reset by remote side
Well I was finally able to update the SMs and the AP but I had to do the process manually. I now have them all up to 7.0.7 and FPGA 051104.
I ended up using CuteFTP Pro to upload the files to each device and then ran the upgrade through Telnet. If I used any other FTP program, the connection would always time out after 40 seconds.
Sadly the upgrade didn’t fix my initial problem. I have devices on my network that I can ping by telnetting into the Canopy, they all respond, but I can’t ping them until I ping them from the Canopy first. Let’s say I have 10.1.4.148, behind on of the SMs. I have a continous ping running to this IP on a monitoring station. If I reboot the AP, the ping never comes back up. Once I telnet into the AP, and ping the IP, the monitoring ping starts working again. Seems like the AP won’t route traffic to this device until it has it in its ARP table.