The AREDN™ Project announces its release of version 3.16.1.1 firmware
This release is a security patch release from our previous 3.16.1.0 release. It is recommended to upgrade all AREDN nodes to 3.16.1.1.
OTA Upgrade Note
In a future release tunnels will be required to be disabled prior to upgrades being permitted on a mesh node.
If you are running a tunnel server or client it is recommended the following steps be performed as in the future similar steps will be mandatory.
- Disable all tunnel server/client connections
- Reboot
- Apply the 3.16.1.1 upgrade
- Re-install tunnels packages
- Enable previously disabled tunnel connection
The following changes have been made from our previous, v3.15.1.0, production release:
Notable Security Patches
- SCS-2017-001 – High Severity
A remote Denial of Service flaw impacting ALL RELEASES of the AREDN/BBHN branded firmware since at least version 0.4.3. Immediate upgrade to 3.16.1.1 (or newer) is recommended to ensure stability of the mesh nodes. - SCS-2016-005 – Low Severity
A number of low severity flaw in dropbear (the ssh server) were reported to AREDN. While these flaws were in 3.16.1.0 they could not be exploited in a default installation as the features were not utilized (CVE-2016-7406, CVE-2016-7407,CVE-2016-7408,CVE-2016-7409)
Data Rate Increase
- 802.11n has been added to the RF protocol. This improves the maximum data rate capability from 54 Mbps to 130 Mbps and allows AREDN nodes to take advantage of the Ubiquiti MIMO (concurrent data channels in both the vertical and horizontal polarization domains), although proportional data rate increases can also be achieved on non-MIMO devices
New Device Support
- Added support for the Ubiquiti AirRouter and AirRouter HP. These are desktop devices with an embedded a 5-port Ethernet switch we have preconfigured for WAN, LAN (ports 1-3) and DtD (port 4)
Upgradability
- The distance parameter entry is now mandatory during initial node setup. Its value can now be entered in either Kilometers or Miles. Testing has proven that data throughput is highly responsive to correctly setting this parameter
- Increased the upload-timeout for pushing firmware upgrades to remote nodes over marginal paths
- Added the ability for packages, such as iPerf, to open firewalls ports at the time of installation
Node/Network Manageability
- Added transmit data throughput values (TxMbps) for Current Neighbors on the Mesh Status screen
- Added a user-specified time zone and NTP server on the Setup page
- Completely rewrote the graphical reporting of SNR to show real-time and 2-day trends for each neighbor
- Added map-based LAT/LON location assistance for nodes with access to the Internet (directly or via a mesh gateway).
- Also added optional LAT/LON “push” to a centralized server which allows users to self-publish their nodes to a public AREDN map
- Added a disclosure statement in the help file on what gets uploaded with the LAT/LON “push” and how it will be used in publishing the public AREDN map
- WIFI Scans are now sortable by column
- Updated the Help page
Running other programs on a node
It has become popular to run an assortment of other programs on a node. And with no need to stand-up an outboard computer, it is a tempting proposition. However, more and more we are seeing nodes run out of memory (most Ubiquiti devices have 32MB RAM, the Rocket has 64MB), particularly by a combination of tunnel services and MeshChat. When this occurs, the node will automatically kill one or more processes. Depending on what it elects to kill, the device may run erratically or reboot. When tunnel services are installed and configured, the AREDN team encourages the use of RPi or other outboard computer for MeshChat.
It has become popular to run an assortment of other programs on a node. And with no need to stand-up an outboard computer, it is a tempting proposition. However, more and more we are seeing nodes run out of memory (most Ubiquiti devices have 32MB RAM, the Rocket has 64MB), particularly by a combination of tunnel services and MeshChat. When this occurs, the node will automatically kill one or more processes. Depending on what it elects to kill, the device may run erratically or reboot. When tunnel services are installed and configured, the AREDN team encourages the use of RPi or other outboard computer for MeshChat.
Incremental Change Lists
v3.16.1.1
- Security Patch: SCS-2017-001 (Remote Denial of Service)
- Security Patch: SCS-2016-005 (DropBear)
v3.16.1.0
- Minor bug fixes
v3.16.1.0b02
- Improved the operation of the distance parameter Kilometers / Miles entry
- Added a “busy spinner” on the SNR Chart to indicate data is being collected and to wait for results
- Added a disclosure statement on what gets uploaded with the optional LAT/LON “push” and how it will be used in publishing the public AREDN map
- Fixed an intermittent upgrade failure with “keep settings”
- Increased the Firmware Upload script timeout from 90 to 240 seconds to allow sufficient time for remote nodes to be updated on marginal links
- Resolved a DNS issue with node name changes
- Resolved a Tunnel firewall issue
- Added support for the Ubiquiti AirRouter (non-HP)
- The TxMbps calculation in Mesh Status improved to more accurately characterize link throughput
- Added a disclosure statement in the help file on what gets uploaded with the LAT/LON “push” and how it will be used in publishing the public AREDN map
- Fixed an issue with programs running on a tunnel client or server node communicating across the tunnel
v3.16.1.0b01
- 802.11n has been added to the RF protocol. This improves the maximum data rate capability from 54 Mbps to 130 Mbps and allows AREDN nodes to take advantage of the Ubiquiti MIMO (concurrent data channels in both the vertical and horizontal polarization domains), although proportional data rate increases can also be achieved on non-MIMO devices
- Added support for the Ubiquiti AirRouter HP, a desktop device with an embedded a 5-port Ethernet switch we have preconfigured for WAN, LAN (ports 1-3) and DtD (port 4)
- Added ability for packages, such as iPerf, to open firewalls ports at the time of installation
- The distance parameter entry is now mandatory during initial node setup. Its value can now be entered in either Kilometers or Miles
- Added transmit data throughput values (TxMbps) for Current Neighbors on the Mesh Status screen
- Decreased SSID Beacon rate from ~10x to ~2x a second. Providing more RF for data on links with multiple nodes, especially on 900MHz and 2.4GHZ at 5MHz wide channels
- Added a user-specified time zone and NTP server on the Setup page
- Completely rewrote the graphical reporting of SNR to show real-time and 2-day trends for each neighbor
- Added map-based LAT/LON location assistance for nodes with access to the Internet (directly or via a mesh gateway).
- Also added optional LAT/LON “push” to a centralized server which allows users to self-publish their nodes to a public AREDN map
- WIFI Scans are now sortable by column
- Updated the Help page
I had some trouble upgrading my M2 Bullet and an Airrouter. I shut down my tunnels, as per the instructions, and uploaded the new software. Had the "save settings" checked. But I couldn't reconnect to the routers after flashing. I ended up doing a hardware reset (both times; I did the bullet and after getting it working, went to do the airrouter, figuring I probably did something incorrectly on the bullet, but had the same issues with the airrouter), The process put it back to 192.168.1.1:8080 and I then had to reconfigure it all. Lucky for me, I thought I might have trouble, saving the tunnel info before starting this. I did get things working again after sufficient cursing...
I have another Ubiquiti node, a nanostation M900 up on a tower, and I'm holding off upgrading its firmware till later. I don't feel like having to get out the ladder to reach it to do hardware resets and whatnot...
Unrelated, I did manage to munge the Airrouter's internal power supply by mistakenly using a 12V wall wart instead of the 5V. I blew up this power supply, and ended up using a linear regulator LM317 set to produce 3.3V With a heat sink inside the Airrouter's case. The Airrouter otherwise survived, and works again.
There is a reason I always carry one of the POE bricks with a reset button. Can plug in to the bottom of the cable without ever having to climb the tower (kind of a necessity when the node is 100ft in the air) --- Should be considered a standard part of the tolkit of any ham working on mesh nodes.
It does issue an ipaddress to my laptop of 192.168.1.19. I did a scan of that subnet and there are no other devices on it.
Any advice is welcomed.
73
Jim K4SPT
Does not connect to http://localnode:8080
There is a DHCP server running, which assigns 192.168.1.x to my laptop LAN connection. It tells me that it is getting it from router "www.ubnt.com".
I can't find any device on that subnet either by scanning the subnet or pinging any IP address or name that I can think of. Haven't be able to find any open port 80 or 8080 on the subnet.
I'm baffled!
73
Jim, K4SPT
disconnect the ethernet cable from your PC
re-connect the ethernet cable from your PC
open your browser
try: http://localnode:8080
The LAN ports at least show a connection and I see a wireless broadcast called "MeshNode" on Ch 11. Both will provide a DHCP address in the 192.168.1.x range.
Otherwise I have been unable to discover any other connectivity.
1) TFTP load of AREDN-factory firmware?
2) 5 second reset button hold (after fully booted) - reset password and enable DHCP
3) 15 second reset button hold (after fully booted) - reset to "pre-configuration" mode
4) other?
2-on AirRouter, held reset button on power up till it entered "recovery mode"
3-TFTP AREDN 3.16.1.0 to 192.168.1.20:69
4-reset laptop to DHCP while AirRouter rebooted
5-accessed http://localnode:8080 after laptop took IP address
6-configured normally
thanks for the data.
It's a lot less agony to upgrade the firmware and have the box "Keep settings" unchecked. Sure, you have to reconfigure, but I ended up doing that as posted above. I did connect a laptop directly into the POE brick's unpowered ethernet jack, as I knew the node would revert to 192.168.1.1 after I flashed it. And found it there.
Oh, I noticed that the masthead you see when you SSH has the old version number.
(FYI, if your node is NOT running 3.16.1.1, the firmware version will show up in RED on the map pop-outs.)
Darrell
I upgraded several nodes:
The OTA one that failed apparently got into some kind of brick mode as the user could not get into it it at all. I may know more when I get it in my hands to fix. Unfortunately that was the node for the PBX (in RPI). And with the old configuration not fully documented, there was some stumbling with the replacement AirGrid device. All is well now. Our phones get a lot of use so it is a relief to have that node back up.
All the nodes had IperfSpeed installed. The direct node and one (successful) OTA node had MeshChat installed. There were no tunnels. I had to reinstall MeshChat as well as IperfSpeed at all locations. The node that failed was one with a very good link path and only one node between it and me.
I like the idea of doing a reboot before any such upgrade.
I found a way to easily and automatically document the current configuration of all our nodes that I have the passwords. I'll explain my method later in a separate post.
I almost forgot to mention: Sometimes during the upgrade I would get a full screen of red text saying that the node would return in 2 minutes, etc. But sometimes I would only get the first couple of lines then after 'seemingly many' seconds later, the rest of the page would be seen. I think there may have been one or two that still only presented those two lines. The one that failed only presented the two lines as I recall.
73 - Mike ab4yy
1 direct, 6 OTA upgrades. One of the OTA failed - the only one running MeshChat. I uploaded, it came back, but at the old firmware revision. tried again and it didn't come back. After a 15s reset press I could ping and telnet in, and then did a "mtd -r erase rootfs_data" and now I could get a broken web interface. (It wouldn't save anything.) Did a third flash of the new firmware, from the web interface, and everything now seems to be OK.
I finally got may hands on the node that failed the OTA update:
Two things of possible interest: (1) I did not do a reboot prior to attempted OTA firmware upgrade; (2) This node was configured a bit different in that the WAN setup was not in the default dhcp state but was set to static with the rest of the fields filled-in different from default. Also this was the PBX and NTP server for our network.
73 - Mike ab4yy
BTW, did you have a PBX running on the NODE?? (shame on you!) or on LAN device attached to the node? (good for you!)
The PBX (FreePBX) was running on a Raspberry Pi.
- Mike
I upgraded 2 nanostation m2 and both will not allow me to set up server.
The main unit had client running. I turned off rebooted and installed the update. rebooted and all seemed ok. When i try to activate the client again its says error :package update failed!
Any thoughts on how to fix??
73
A remote Denial of Service flaw impacting ALL RELEASES of the AREDN/BBHN branded firmware since at least version 0.4.3. Immediate upgrade to 3.16.1.1 (or newer) is recommended to ensure stability of the mesh nodes.
I guess this means I should retire the Linksys routers I have running BBHN on my network... ? That I have DtD to my Ubiquiti nodes running the latest AREDN firmware. I don't think that 3.16.1.1 is usable on Linksys routers.
My advice would be to ask the BBHN team what the plan is from their side on this issue before you make a final decision as they control the release cycle for devices running BBHN firmware.