I just updated 2 of my test nodes to 3.18.9.0. Ultimately, I was successful, but it was not without issues. Both nodes had been running 3.17.1.0RC1.
System 1 - Rocket M2 (XM)
I may just make the tftp procedure my default with my other test nodes.
Rob
System 1 - Rocket M2 (XM)
- Using the UI to upgrade the node seemed to work at first, but the system never came back. Looking at the lights on the Rocket, the activity light would be flashing, then it would stop and the middle status lights would quickly flash (one green, one yellow). Then this pattern would repeat. I could not connect to the node.
- I then did a factory reset and tftp'd the factory 3.18.9.0 image onto the node. I had an odd issue with the browser (Chrome, WIn10) where the page would load, but as soon as you changed anything you'd get an "unreachable" error message. After trying a number of things I rebooted my laptop and this resolved the issue. I realized that when the Rocket came back (earlier), it never asked me for the node userid/password. So looks like a browser thing.
- I was unable to get the UI to do an upgrade. I'd select the sysupdate image, but the "Upload" button remained grayed out (Note: the button was grayed out even before I selected the file). Rebooted the node, restarted the browser, etc. but no luck.
- The tftp procedure was successful and I had no issues once it was up and running.
I may just make the tftp procedure my default with my other test nodes.
Rob
2) the help page on-node has the answer.
Administration
Note:
Files can not be uploaded to a node while a tunnel server or client connection is enabled. To upload any file (firmware, package or ssh key) you must ensure all tunnel servers and clients are disabled.
Upload buttons will be disabled until tunnels are disabled.
2. Indeed. It occurred to me long after posting the note that I had set a tunnel server up on this node last year as a test. Forgot about it since I had not used it in so long, but I should have checked for that. It's been so long since I did an upgrade that I'm a bit rusty ;-)
Thanks, Darryl.
Rob
Took screen capture of tunnels, turned tunnels off, upgraded to 3.18.9.0. It went fine. Had to re-install tunnels. All settings were there, just checked them back on.
Mesh chat was missing/not installed. Chose the file to upload, but the upload button stays grayed out, like it doesn't like the version??
Needs a version upgrade??
Brent, Same here. I got the latest from Trevor's Page but the button stays gray.
Regards Rick
EDIT: Thanks to Daryl, I unchecked the tunnel, downloaded the MeshChat IPK and all is now well. As we used to say in the Military RTFB.
Try these steps.
First get the download of 3.16.1.1 from the node Admin screen. This will default the login and password to root/hsmm. Once it comes up, change the password, save it and reboot.
Download the sysupgrade version for the M9 Nanoloco to your PC from the AREDNMESH.ORG web site.
You should upload it to the node from the Admin panel. I had to do this for nodes runing the defunct 3.17 (rc) code and everything worked fine.
73, Gordon Beattie W2TTT
Gordon, thanks for the post. Could you clarify: for your 3.17rc nodes, you took them back to vanilla 3.16.1.1before upgrading to the new release?
Thanks,
- Don - AA7AU
ps; seeing all the problems posted from several folks, I think I'll hold off the upgrade until things settle out. Kinda confused at this point.
For the upgrade:
1) if you have MeshChat or other 3rd party packages installed, remove them.
2) reboot the node
3) if you have internet provided to the node, go to the ADMIN page and click REFRESH to download the list of appropriate firmware images.
4) click DOWNLOAD to install it.
The issues I've seen are:
- not enough storage space due to other packages
- not enough memory (just reboot to clear)
- loading the incorrect firmware file
Go for it!
Yes in just about all cases the most current option offered to Download after a refresh of a 3.17 (rc) nodes was 3.16.1.1. We did that and it would wipe the password back to the default value of "hsmm", but with no other issues. I would then update the password, save it and reboot before uploading the 3.18.9 code that I obtained on my laptop or tablet from the www.arednmesh.org web site. After that automatic reboot, all was well.
Today when upgrading a pre-November 2017 Nanostation 5 XW node from the 3.17(rc) code, Inwas only offered release 3,.15.1.1 to Download.
I took that option and followed th e same steps successfully.
73,
Gordon Beattie W2TTT
201.314.6964
I have a need to set rfc1918_filter 0 in /etc/config.mesh/uhttpd in two of my units.
After the upgrade to 3.18.9.0 this does not seem to work any more - I get the error message (Rejected request from RFC1918 IP to public server address) even though I have turned the filter off. This is a Rocket M5GPS.
Just to summarize - turning off the RFC1918 filter in the config file did not work on either my M5GPS nor my airGrid after upgrade to 3.18.9.0.
With Joe's help, I found that one can edit the /etc/init.d/uhttpd file to take out the line pertaining to RFC1918 and then the filter never goes in, in the first place.
Clearly this is just a work-around and not a fix for the problem. But it does the job.
Were the 2 posts, directly above, intended to be posted in this thread: https://www.arednmesh.org/content/integrating-aredn-existing-network#new ?
Andre
Well, after almost perfect upgrades across a bunch of different Ubiquiti devices including Airgrids/Bullets (M2/M5), NBEs (M5), Nanolocos (M9), Nanostations (M2/M5) and Rockets (M9/M2/M5), we may have finally encountered an upgraded node that didn't work well.
After upgrading two M5 XW Nanostations we discovered that their respective Foscam cameras were not receiving an IP address. We tried to reboot them with a Macbook on the correct (LAN) port and still no IP was provided. These two port devices are fraught with peril, so out of an abundance of caution, we simply downgraded to release 3.16.1.1 and all worked fine with either the camera or the Macbook getting an IP from the M5 XW Nanostation. For reference, the two nodes had different types of Foscam devices: one had an 89XX fixed camera and another had a PTZ.
We also compared this to M5 Rockets and M2 Nanostations running 3.18.9.0 and they had no problems. Is there something we are missing about these M5 XW Nanostations that is specific to this release of code?
Anyone else have this issue with the M5 XW Nanostation?
Thanks!
Gordon Beattie, W2TTT
201.314.6964
tcpdump -i eth0.0 -w /tmp/lan.pcap
If you get this pcap file, we can look through it to see what is going on. Also, a support data download.
One of our team members provided the following.
Even though it’s a possibility that the camera times out the lease request, I don’t think this is the problem.
The macbook used was disconnected and re-connected multiple times after the DHCP was up and running (assuming) and yet, it had no lease.
Another thing, if the problem is indeed a delayed DHCP server startup time, this still posts a problem in comparison to the older version which does not impose this problem.
An update should not slow down the system.
I would still like to run the tcp dump and see what exactly is happening.
Another thing we may want to try, is install 3.18.9 as a clean install instead of an upgrade. Probably the problem has to do with retained setting including the DHCP reservations.
Aly Badawy (AL0Y)
District Emergency Coordinator (Passaic County, NJ)
Amateur Radio Emergency Service
ARRL Official Relay station
NNJ Section, Hudson Division
RRI Registered Operator
AL0Y@WB2FTX.#NNJ.NJ.USA.NOAM
MeshPhone: 973-3301 | Cell: (862)276-8263
aly@al0y.com | http://al0y.com
Reference: https://github.com/aredn/aredn_ar71xx/issues/221
We are seeing different behavior from the drivers that manage switches in devices. I suspect what is happening, is the vlan functionality is not removing the tag from packets for the LAN. Due to limitations on how this worked in prior OpenWRT releases, the NSM5 XW is configured with the LAN port on "eth0.0". What this means is using a vlan tag of '0'. In prior releases this tag is stripped off when the packet goes to the devices on the LAN. I suspect what is happening, is the driver is no longer stripping off this tag. Now generally devices should interpret a vlan tag of '0' the same as untagged packets. I suspect the foscams and macbook are not doing this, rather ignoring the packet as if it was another vlan.
The good news is that the new behavior may allow us to have dtdlink/lan/wan all on the same port on the NS M5 XW consistent with other devices. However, if the driver is leaving a '0' tag on the packets, this could be problematic. I'll need to investigate the various config options to see the packet vlan tag handling to determine the path forward and confirm my suspicions.
Joe AE6XE
By using tag '0', we can combine LAN/DtDLin/WAN on the same port and have this benefit like other mesh nodes--can be done with the NS M5 XW. But as discussed already, the negative is some devices will not work -- do not interpret tag 0 as untagged. (the "1t" entries in swconfig and/or live network config file change to "5t".)
If anyone is 802.1Q knowledgeable and wants to dig into the code of this linux driver, maybe we can find a fix. I'm not optimistic, if it was an easy task, the guru's behind developing the 802.1Q opensource driver used in the entire linux user community would have already done this. The other possibility is that we are overlooking something. Even the OpenWRT sample configs show both tagged and untagged usage on the same port (3 in the example), but so far unable to reproduce:
https://openwrt.org/docs/guide-user/network/vlan/switch_configuration
If anyone has interest and time, might be worth another set of eys looking into trying various config combinations to see if something is being overlooked.
Joe AE6XE
Just a question, and not pushing anything on your todo list, but is this still being looked at? any hope for having a one port configuration for the nanostations XW?
I tried to follow the link to the gitHub issue page and it looks like this issue is no longer found.
is it dismissed at this point?
thanks
73 de AL0Y
Joe AE6XE
The other referenced issue, with modified vlan settings (combining dtdlink with LAN on same port) is not stripping off the vlan tag, and this is the scenario where a non-802.1q aware LAN device would have trouble.
Joe AE6XE