I have upgraded 3 units (NanoBridgeM5 and two Rocket M5's) from the 2015 Production to the 2016 Beta01 and none of the units kept the settings and reverted to "fresh install" requiring full setup. I understand that we need to reload the Tunnel applications, bu I believe that we were able to successfully perform OTA upgrades without losing the setup information.
Is this a bug or should it not work??
You are here
2016 Firmware upgrade with OTA not keeping settings?
Sun, 01/31/2016 - 23:28
#1
k1ky
2016 Firmware upgrade with OTA not keeping settings?
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
I'm unable to duplicate this:
Did you accidentally uncheck the keep settings box?
By 2015 build do you perhaps mean 3.0.2 which requires you to apply a patch first?
Are you allowing the node enough time to set it self up and reboot twice after the upgrade (several minutes) as during the first reboot it will be unconfigured and ID interrupted might not go through the auto configure process.
No one has been able to reproduce this here in our labs locally so a support file where it's is absolutely needed before this issue can go any further.
Also did you have tunnels installed or not? (99% my testing personally is without tunnels but I hear dozens of others with tunnels not having issues either but curious if there is perhaps a link)
How do I get a support file from the node without going into the configuration screens? Also the node has been remotely rebooted multiple times through a smart outlet strip, so I may not have any good logs for you anyway.
Support dump may still be useful, but yes if its been rebooted we may not have the data, but its still worth getting a copy of to see if we get lucky.
Everything I'm seeing from the support file I received from you seems to point to the checkbox having been unchecked.
None of the settings appear to have been saved, everything looks like a fresh install with no signs of anything having been retained. This really should only happen if the chebkox is unset.
Going out on a limb however to make sure we cover all the bases, what browser(and its version) did you use to do the upgrade? Just incase we are hitting some weird browser bug on the form submission.
This might be a small bug just thought I would let u know
Thanks
I upgraded from 3.15.1 to 3.16 beta and one node showed the firmware updating screen, and when it came up. it still had 3.15.1 on it.
I had to upload the beta again. Thought maybe I had selected the wrong file when uploading, but had it happen on another node.
All of my nodes, lost all settings when upgrading to the 3.16 beta.
Had to re-install the Tunnel.
Another issue: Making any changes to ports or services, the firewall file gets re-written and removes the tunnel port rule.
Last issue: With tunnel active, I cannot ping or access nodes on the other side of the tunnel.
Currently testing on the AirRouter HP.
I had the same issue with the Tunnel usign a NanoStation. If I down rev'd to 3.15.1 everything worked fine. All of the issues returned when putting 3.16 beta back on.
Unable to perform the same test as I do not see a 3.15.1 version for the AirRouter HP
Regarding lost settings: I still need a support dump from someone to do anything more. Reinstalling the tunnel however is an expected mandatory requirement of the upgrade as it will not be kept across the upgrade.
Last Issue with client itself cant be pinged that is beeing looked we need a support dump from BOTH sides to finish looking at that one, so far we haven't gotten that so its just sitting so if you can get a support file from each side we can look at that.
Regarding the firewall rule overwrite: I'll go ahead and look into this with the tunnel team to see about that.
As Conrad stated, you do need to hit the "Install Tunnel" button to install the binaries after a sysupgrade.
HOWEVER, your tunnel server and client settings are saved during the sysupgrade.
The issue of wiping out all settings on installation happened (Locally) to a Bullet, Nanostation and Nanostation Loco.
Updated a node with OTA to a node on a Mountain, and it took a couple tries before updating. It did go thru the "Updating Firmware" screens each try.
(Tunnel / Ping Issue)
Was running the Nanostation M2 and tunneled.
With version 3.15.1 the Tunnel worked fine, no issues.
Installed the 3.16 beta, and was was not able to ping, scp, or ssh any node on the other end of the Tunnel.
Restored the NanoStation to 3.15.1 and everything returned to working properly.
With the announcement of the Beta and AirRouter I decided to purchase the AirRouter and give 3.16 beta a try again.
This node is experiencing the exact same issues with the tunnel as the NanoStation did. Once the Tunnel is installed I loose the ability to ping other nodes.
I can however connect to those node via the Web Browser.
I reinstalled the 3.16 beta fresh. Installed the tunnel package and tested the tunnel prior to capturing the support dump.
Only changes to the node are changing the tunnel port number as my provider is blocking the default port as well as others using the same provider.
Confirmed the rule for tunnel is wiped out of the firewall file with any save to the port / services page.
Here is the support dump from the AirRouter HP. Hope it helps.
I do not have a support dump of the other end of the station as I don't own it.
A long shot...worth investigating???
However this wouldn't make sense on remote nodes and as such is probably NOT the cause.
"For unknown reasons such a cold reset has often been reported to be necessary after a sysupgrade. This is very very bad in case you performed this remotely!"
The AREDN process does a reboot twice, and I speculate this issue is occurring and the state of the node is half-way through the AREDN upgrade process.
But, let's be cautions to over react--and I exaggerate for effect--we don't want to stop swimming in the pacific because 1 person last year got bit by a Shark in the Atlantic. My experience is that this odd behavior is on very rare and occurs with a 'cursed' device (yes, this is a technical term ;) !). I've been fortunate, that none of the Rockets (M2, M3, & M5) I have up on mountain tops are cursed--and I've used "keep settings" 20+ times without issue to have confidence. But I do have this one NanoStation...
Joe AE6XE
We have also seen OpenWRT documentation wrong on numerous occasions as well.
Do you have a support dump or a serial log Joe of the symptoms your speaking of? And are you speaking of coming up as NOCALL or something else on this NanoStation?
I thought I would add my experience:
I had a Bullet with the Beta 15 firmware and tried the OTA upgrade to 15.1 and it worked fine. I did it via the download and had another node set as a WAN.
After the upgrade everything was fine.
When I go back to admin and refresh the download box, I only got the 15.1 production version and one 3.0 older version.
So I downloaded the 3.16.1.0b01 to my PC and used the upload function to the node.
The node did not recover and reverted to an IP of 192.168.1.1 and radiated a SSID of "MESHNODE"
I could not connect to the node at 192.168.1.1:8080
When it did connect, I got the redirecting to status page message and then a timeout.
I tried repowering several time with the same result and could not get a response by connecting the the MESHNODE either. (although the wifi did connect)
Finally, I did a long reset (20 sec) via the POE and got an immediate response.
Of course, it was now NOCALL with no settings.
I reentered the settings and all is well.
I actually saw briefly a screen with my call in the process before the reset but it would not respond. It seemed that there was something corrupted in memory.
I also should have mentioned that after the OTA failed I plugged the node directly into a PC.
One final note, I had to use the distance slider. Entering a number directly did not work.
N8JJ
To recap, I had done an OTA upgrade on multiple nanobridge nodes with no issue. Then I got to my HEYELE node...when I did the upgrade, the node didn't come back. I had to visit the site, and I was unable to get into the node while there. I ended up swapping it out with another nanobridge. When I brought the first one home, it was in the NOCALL state.
Fast forward to this week. I felt lucky so I did an OTA of the last of my nodes. I really wanted to try out the new N stuff as well as the charts to track some problems I've been having with a link. I loaded the 240sec update patch, it rebooted, then I did the 3.16b1 update. No issues. Yay.
Today I loaded the 240sec patch on the node I had replaced when my first node didn't update (the HEYELE site). The reboot worked. Everything looked good. I loaded 3.16b1 and guess what...it didn't come back. Luckily I had a spare hour so gear up, PPE on, check into the controlled access site, and up to the node. I plugged my laptop in the LAN port and got a link light, but no DHCP. I tried manually setting it to the 192.168.1.x subnet, but the node wasn't there on .20 or .1. I finally did the remote reset on the power brick and got it to come up in NOCALL mode. I reset the settings and everything was fine.
So what's unique about this site?
1. It's a mesh gateway node.
2. The gateway IP address is fixed...192.168.1.3/255.255.255.0 with a gateway of 192.168.1.1.
3. It's hooked to a netgeat switch with VLANs setup.
4. The internet router is on 192.168.1.1.
5. It was running 3.15.1.
6. It had just been rebooted.
7. No services.
8. No tunnels.
Dev team, does anything stand out about this config? I can attempt to recreate this in my lab later in the week if needed - I've got a few spare nanobridges.
Mike, KG9DW
We are fairly certain that we know the cause. Working on the solution now for Beta 2
I upgraded my airRouter to beta 2 here with no problem. That is a direct connection to the shack computer. Then I used that connection to do an OTA SysUpgrade to one of my M2's - and it did not come back. It had the same problem as previous postings: If you connect direct to it and run an IP scan, you will find something on 192.168.1.1, but no ports open or responses to pings. Power on reset of 15+ seconds puts it in the TFTP server mode on 192.168.1.20 and you can upload the factory bin file with a TFTP client and enter your callsign, etc., again.
Can you reproduce this with beta 2 on the node and trying to go to beta 2 (upgrade in place to same version) ?
if so a support dump from BEFORE the upgrade may be useful for testing.
on a suggestion from K1KY I put in the "slow link" patch and tried another Rocket M2.
This time it worked.
I would not consider the LINK to be slow as it is 1 hop running at 28 Mbps and 100% LQ. It must just be the amount of time it takes the program to burn-in....