You are here

A Tale of Two Air Router Upgrades to Dev 156

13 posts / 0 new
Last post
N2MH
N2MH's picture
A Tale of Two Air Router Upgrades to Dev 156

This afternoon, I attempted to upgrade two Air Routers to the dev 156 code from stock 3.16.1.0 code. One went well and the other didn't. I did the upgrade by attaching the nodes to a local computer and only using the LAN port on the node to connect to the pc. These were not over the air upgrades. Both nodes had the save configs box checked.

The one that went well was an Air Router that had never been used. It was previously flashed successfully to 3.16.1.0 code and had some basic configuration done: Node Name, password, channel. No tunnel code was loaded. And, it was tested over the air and meshed with other local nodes. I flashed with the sysupgrade code and all went well. The node came back to life with its original node name and appeared to be healthy. I then connected the WAN port, downloaded the tunnel code, and then proceeded to configure a tunnel client which came up immediately. Thus, it looks like this node is healthy and usable.

The other node was also an Air router using 3.16.10 code and has been in service for several months as a tunnel client. Before upgrading, I took screen shots of all the configs. I then turned off the tunnel. As done with the first node, I upgraded locally using the same sysupgrade code. After the normal wait, the web browser would not refresh with a display. Doing the usual, resetting the pc's dhcp client and purging the browser's cache, still NG. I then went to the pc's command prompt and found that the pc had been issued 192.168.1.6 as an address and the node was 192.168.1.1. Ping, telnet, ssh, web to that address were not successful. I then plugged in my home network to the WAN port. After finding an address, I found I could ssh into the node by using root and my original password. Screen shot of what I saw follows:

<pre>
BusyBox v1.23.2 (2016-12-12 23:22:29 UTC) built-in shell (ash)

              _____  ______ _____  _   _
        /\   |  __ \|  ____|  __ \| \ | |TM
       /  \  | |__) | |__  | |  | |  \| |
      / /\ \ |  _  /|  __| | |  | | . ` |
     / ____ \| | \ \| |____| |__| | |\  |
    /_/    \_\_|  \_\______|_____/|_| \_|
    AMATEUR  RADIO EMERGENCY DATA NETWORK
              Release 3.16.1.0
-----------------------------------------------
   BASED ON OpenWRT BARRIER BREAKER r42549
-----------------------------------------------
 * 1 Battery          Connect all devices
 * 2 POE injectors    Upgrade firmware to AREDN
 * 3 cat5 cables      Setup with your callsign
 * 1 UBNT NanoStation Point the Antenna
 * 1 ipCam            Welcome to the Mesh!
-----------------------------------------------

root@NOCALL:~#
</pre>

Once in, things looked pretty normal except for the <pre>root@NOCALL</pre>. Thus, it would seem that the linux engine is working OK. Note that the node is still on Barrier Breaker, 3.16.1.0.....

My question is this: Is there a command I can issue from the node's command prompt to kick it and get it to complete the upgrade?

73, Mark, N2MH

 

K5DLQ
K5DLQ's picture
1) this could be a memory
1) this could be a memory constraint issue with tunnels.  Since your node was a tunnel client, it receives it's config info for tunnels (ie. compression/encryption) from the tunnel server.  in 3.16.1.0 (and all tunnel versions prior), the default setting for tunnel compression was enabled and consumed a large amount of memory.  In the develop branch, that has been corrected.  HOWEVER, it is will only be make effective if the tunnel SERVER is running develop branch code.

2) once the node is in the "NOCALL" (pre-config) state, all of the prior configuration info is gone.  (unfortunately).

3) perhaps, a best practice to upgrade (when tunnel clients/servers) are installed, is to disable tunnels AND REBOOT before proceeding.

 
N2MH
N2MH's picture
Thanks for the info. So, I

Thanks for the info. So, I guess there is no answer to my question. I'll have to revive this node the hard way, perhaps with a 15 second reset. About the AND REBOOT addition, I'll have to let you know next year when I can do another one.
 

K5DLQ
K5DLQ's picture
Check if it broadcasting wifi
Check if it broadcasting wifi said of MeshNode.  If so, just connect with wifi and configure as normal
k1ky
k1ky's picture
DISABLE / REMOVE and REBOOT
I believe my "failsafe" method includes removal of the Tunnel module from the node, save and reboot. Then install the new Firmware.  I'll try that next time and report back. Ditto Mark's experience today except mine was with a Nanobridge M5.  It goes to Channel 34 broadcasting an SSID of MESHNODE.  I see the instructions for grabbing a Support Dump from an ssh session - that should be helpful and I'll try to run that on my next one.
k1ky
k1ky's picture
No go Develop 156 to Develop 158 with Tunnel - not smooth transf

I turned off the Tunnel Server incoming client connection checkboxes, saved settings, rebooted, removed the tunnel from Develop 156, saved and rebooted.  Tried upgrade to Develop 158 and the unit ended up as MeshNode broadcasting on Channel 36 - 192.168.1.1 "stupid mode".  Nanobridge M5 with Bullet Develop 156 Code.  Unable to get a support dump on this one, there is definitely a problem. 

Once I recovered the unit, it came back as NOCALL with the Develop 158 code intact.  Re-installed Tunnel and reset settings - all good to go again.
 

KG6JEI
Unfortunately it sounds like
Unfortunately it sounds like you have wiped out the data we require to investigate this issue further.

As noted in this thread before we really need someone to leave it in this state and work with the team not just continue on if they want us to be able to diagnose these issues and provide a fix.
KG6JEI
Check the /etc/mesh-release

Check the /etc/mesh-release file for the version.

The Banner isn't accurate in the current nightly builds (commits are sitting in code review staging right now to fix them)

The web user interface and the mesh-release file correctly show the build info at this time.  Its possible you are on develop 156.

Also a support data file may give more info as well (and would be mandatory for really anyone to look into this)


 

N2MH
N2MH's picture
root@NOCALL:~# cat /etc/mesh

root@NOCALL:~# cat /etc/mesh-release
develop-156-37a7b57c
root@NOCALL:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Chaos Calmer'
DISTRIB_REVISION='r48676'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05.1'
DISTRIB_TAINTS=''
root@NOCALL:~#

So, it looks like Chaos Calmer is really there. And, this is develop-156.

Re: support file - Since I can only get into the node via ssh, I tried running ./supporttool in the /www/cgi-bin directory. Unfortunately, it only returned binary gibberish. I can't log in via a web browser, so I can't get the support file that way. Sorry I didn't grab one before the upgrade.

KG6JEI
Run ./supportool > /tmp
Run ./supportool > /tmp/output.bin and copy the file off node (SCP).
N2MH
N2MH's picture
No Can Do

Sorry, can't do that anymore. I did the 15 second restart which got me back to the point that I could start to configure things and get going. I have one more node to do after this one. I'll try to repeat this process and then get you that support file. Unfortunately, it looks like I won't be able to do that until after the first of the year.

The node now appears to be running normally and I'm putting all my configs back in (printed paper screen dumps are a good thing!)
 

KG6JEI
In the future when coming
In the future when coming across issues in the snapshot build please do not jump past allowing the dev team a chance to look into the issues.

This is around the 5th time I believe somone has reported similar symptoms and every single time has not allowed the dev team a chance to look into the issues.

If no one works with the dev team these issues will persist indefinitely.
K5DLQ
K5DLQ's picture
BTW, develop-158 has the
BTW, develop-158 has the properly identified banner file now. (Chaos Calmer)

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer