You are here

NSM5 XW unresponsive after update to 3.17.1.0RC1

7 posts / 0 new
Last post
KG7LMI
KG7LMI's picture
NSM5 XW unresponsive after update to 3.17.1.0RC1
UPDATE: I tried 3.16.1.1 one more time, and now it responds on localnode:8080. No idea why the others did not work, but I am going to try 3.17 again. UPDATE 2: I was able to update to 3.17RC1 from 3.16.1.1 this time. That was fun (not). Is there a way to delete posts? This is now useless ... ---- I have an NSM5 XW that was running 3.16.1.1 with no issues. We are planning to add some Rocket M5 XW nodes that require 3.17RC1 so I decided to update the NSM5s to this also. I followed the normal procedure (sysupgrade image) to update, and it seemed to go fine. However, when the NS finished booting, it assigned my laptop the address 192.168.1.20. Very odd. I scanned for IP addresses and ran Wireshark, and there is a Ubiquiti node reporting at 192.68.1.1. I can ping it but that's it - I cannot log into the web page at 192.168.1.1 - refused connection. I tried the other "usual suspects" addresses, ipconfig /release & /renew, etc. So I put it in recovery mode and TFTP'd the NS back to XW.v5.5-10u2 which was successful. I then used AirOS to upload the 3.17 (factory) release and the same thing happened. Then I tried TFTP'ing the 3.17 factory image directly with the same results. Finally, I TFTP'd AirOS again then uploaded the 3.16.1.1 XW factory image to at least try and get back to where I started, but the same odd DHCP address allocation is still happening. Before I try this on other nodes, I'd like to get this resolved and understand why it happened. Net/net, I can get AirOS to work fine but no AREDN image will work. Does anyone know what is happening? I searched the forum for issues with 192.168.1.20 as an assigned (not node) address with no luck. 73, Rob
K5DLQ
K5DLQ's picture
it is in Pre-config state if
it is in Pre-config state if it is giving out 192.168.1.x addresses.
Close your browser.
unplug your network cable
plug in you network cable
open your browser
try to go to:   localnode.local.mesh:8080
If that doesn't work, try:   192.168.1.1:8080
If that doesn't work, try connecting via wifi to ssid: MESHNODE and repeating the above 3 steps.

Go thru the normal configuration.

 
KG7LMI
KG7LMI's picture
Thanks for the response.
Thanks for the response. As I mentioned in the update, it is working now. I don't know why the first few attempts failed. Up into the last attempt, the Ethernet status did NOT have local.mesh as the connection-specific DNS domain (and I did not think to try 192.168.1.1:8080 - I will add that to my notes.) Probably pilot error somewhere along the way ... although I did disable and re-enable the Ethernet port before that for the first time in this process, so perhaps this was a Windows issue all along?? Thanks again - you guys are really responsive. 73, Rob
K5DLQ
K5DLQ's picture
No worries.  Glad you got it
No worries.  Glad you got it working.
We have made some improvements in 3.17.1.0+ to reduce the likelyhood of losing config (ie. going back to pre-config state) during a sysupgrade.
 
KG7LMI
KG7LMI's picture
Cool. What's the timeframe
Cool. What's the timeframe for the next 3.17 release? I just ordered our Rocket M5s for our first mountaintop PtP deployment and they should be here next week, so I'd like to figure that into the test & deployment schedule. Rob
K5DLQ
K5DLQ's picture
Unsure.  We have 1 blocker
Unsure.  We have 1 blocker right now.
KG7LMI
KG7LMI's picture
Understood. Thanks. 73, Rob
Understood. Thanks. 73, Rob

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer