AREDN Release Notes v3.18.9.0 – 26 September 2018

The AREDN team is pleased to announce the general availability of the latest stable release of AREDN firmware.

This release includes many significant improvements in the underlying OpenWRT code during the last 4 years, from July 2014 to August 2018. It also introduces a major upgrade in OLSR from version 0.6.7 to version 0.9.6.2.

Details of the OpenWRT changes are found at the following links:
OpenWRT 18.6.0 – First Stable Release – July 2018
OpenWRT 18.06.1 Service Release
OpenWRT Version History
 

List of Changes

1. AREDN firmware is now based on the most recent stable version of OpenWRT 18.06.1 released in August 2018. This includes a current version of the Linux kernel. This improvement is significant in that it enables AREDN firmware to benefit from the many bug fixes, security improvements and feature enhancements provided by developers around the world.

2. Current AREDN software can be loaded onto any supported (or ‘in testing’) Ubiquiti device by using the TFTP method.   If the version of AirOS is v5.5 or lower, then the AirOS Web Interface may be used to load AREDN.   The bootloader provided with AirOS 5.6 and higher will check for official “signed Ubiquiti firmware” before loading via the AirOS Web Interface.  Since AREDN firmware is not signed by Ubiquiti, this will fail.  However, TFTP should continue to work.

3. The firmware now officially supports many of new Ubiquiti XW devices that were not supported on AREDN versions 3.16.x.x The current supported devices list is found at https://www.arednmesh.org/content/supported-platform-matrix

4. AREDN firmware is now available for specific Mikrotik Basebox models. The specific devices are the Mikrotik BaseBox 2 RB912UAG-2HPnD and the Mikrotik BaseBox 5 RB912UAG-5HPnD. The installation process requires some familiarity with Linux commands. The installation instructions are found at https://www.arednmesh.org/content/installation-instructions-mikrotik-devices

5. Main Node Status Page Changes - The SSID, Channel Number and Bandwidth are now displayed on the main page. An optional node description, if it is supplied on the Setup page,  is displayed on the main page just below the node name.

6. Firmware was updated to address changes in the latest versions of TP-Link hardware, CPE210 and CPE510 version 1.1,  version 2 and version 3.

7. The links to the firmware and packages repositories on the Setup page were updated to point to the new AREDN Inc. servers.

8. The Node Name field size on the Basic Setup page was increased to 50 characters.

9. Sysinfo.json was updated to display the  node’s current time, node uptime, load average and locally hosted services.

10. The AREDN firmware filenames were shortened.

11. Several previously installed but unnecessary packages, including IPv6 packages, were removed to increase the available memory. To be clear, IPv6 was never implemented in any version of AREDN or BBHN firmware. The code to support IPv6 was compiled into the firmware, took up space, and performed no necessary functions.

12. For performance reporting the iperf package was updated to iperf3.

13. In some circumstances, insufficient DHCP addresses were available from a given node. It is now possible to enable a node to issue up to 29 DHCP IP addresses. The previous options for issuing 1, 5 and 13 IP addresses remain in effect, with 5 addresses as the default.

14. The firmware Contributors file was updated to include Andrew Cameron - KK4ZUZ, Jason Brady – KF5DEB, and Eric Satterlee – KG6WXC.

15.  The Powerbridge device was added to the list of supported devices.

16. The signal-to-noise ratio (SNR) displays above the real-time chart. This improved display is very helpful when you are on the tower and you have someone below reading you the SNR to optimize the antenna azimuth and tilt. Without the SNR number it was hard to tell exactly from the chart whether changes in antenna azimuth and tilt result in improved link quality other than a relatively gross better / worse condition.

17. The AREDN firmware web pages are now accessible via HTTP port 80. The means that is no longer necessary to put port 8080 (:8080) into your web browser to display the device page at localnode.local .mesh. The uhttpd listens on both ports 80 and 8080. The internal firewall rules were updated to include this change.

18. There is a new feature to show the OLSR Routing Table Size. This feature enables a new type of statistic to indicate the number of entries in the OLSR routing table. This statistic should be displayed on a node's main page as well as the Mesh Status page. Currently, the Mesh Status page (aka the Nodes List) shows most of this information but makes no attempt to quantify it.
    In addition, this statistic would count additional entries that are not nodes, reserved addresses or advertised services such as tunnel networks.
    Visually, this statistic appears right after memory usage.
    By adding this new statistic, network operators may be able to get a handle on when a network grows too large for either available memory or cpu power to process a large routing table in a timely manner when making individual packet routing decisions.

19. There is a new feature to add a node description to the Mesh Status page.  The display of the new Node Description text at the top of the Mesh Status Screen is consistent with the main node web page screen. The description field is multi-line.
     
20. There is a new feature to add a display of the node’s Latitude and Longitude on the main page. This information may act as an antenna pointing aid for new users.
     
21. Mesh Status page improvements include "(tun)" next to a Mesh Node in the "Current Neighbors" column indicates the path to the Neighbor is over an Internet tunnel.  "(tun*?)" next to a mesh node in the "Remote Nodes" column indicates the node has tunnel links over the internet to connect mesh islands together. "?" is a number indicating the count of tunnel connections the node has.
     
22. Custom firewall rules will be preserved during a sysupgrade.  Groups with custom rules created in /etc/local/mesh-firewall for echolink, ampr.net, and other integrations with Internet based applications can preserve rules across a firmware upgrade by locating the custom rules in this directory using a file named 59-custom-rules.
     
23. Restructured sysinfo.json output to have a better organization. The location information is now under:
    "location": {
    "lon": "-95.558470",
    "lat": "30.227114",
    "grid_square": "EM20ff" },
    and mesh RF settings are under:
    "meshrf": {
    "chanbw": "5",
    "ssid": "AREDNTEST-5-v3",
    "channel": "-1" },
     
24. Added preliminary support for Mikrotik hAP ac Lite product ​RB952Ui-5ac2nD. The 2.4 GHZ MIMO radios will access and AREDN mesh network. We plan to use the 5 GHz radio as a normal WiFi access point for computers, tablets and smartphones.
     
25. Ubiquiti XW devices - a reminder that the XW boards use a different Ethernet chip and require that WAN and DtD connections are made from the SECONDARY port of the device. This applies to both M2 and M5 devices.
     
26. Using the WiFi Scan button now requires the node operator to login to the node.
    
    The WiFi scan button triggers RF emissions up and down the channels of the band.   It means the control operator of the device no longer has limited the emissions to the assigned channel and, without a login, would give up control of the emissions to other mesh users.    For example, a scan will trigger emissions in the 5GHz band to possibly interfere with a nearby Doppler Radar system in the local area, should there be one.   AREDN has not dynamically detected radar pulses in these "DFS" channels and will not prevent emissions like a home WiFi Access Point would.
    
    Consequently, due to an abundance of caution, the password access for the node owner was added. 

Images built

Known Issues

The following issues remain and have not been addressed in this release.
1.    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 (many Ubiquiti devices have 32MB, however the more recent, XW devices typically have 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.
2. The primary manifestations of this issue are the slow response to user interface screens; low Free Memory (<4MB) and high CPU Load Average (>4%) as displayed on the Node Status screen.

In Case You Missed It

There were several improvements and fixes that we carried forward from the recent version 3.16.2.0 firmware release.

1. Main Node Status Page Changes - The OLSR Status button was removed from the main Node Status page due to a flaw in it which causes OLSR restarts. Removing the OLSR Status display also increased the memory available for other operations. To see the OLSR status information, use the following Linux command in a terminal session when logged into a device: echo /all | nc localnode 2006   Alternatively, you can use the following URL in a browser window on any mesh connected node to display the same information: http://localnode:9090/all   
    

2. The dnsmasq package was upgraded to the current available version with numerous security patches. This code performs the DNS and DHCP functions.

1. Using the WiFi Scan button now requires the node operator to login to the node.
   
   The WiFi scan button triggers RF emissions up and down the channels of the band.   It means the control operator of the device no longer has limited the emissions to the assigned channel and, without a login, would give up control of the emissions to other mesh users.    For example, a scan will trigger emissions in the 5GHz band to possibly interfere with a nearby Doppler Radar system in the local area, should there be one.   AREDN has not dynamically detected radar pulses in these "DFS" channels and will not prevent emissions like a home WiFi Access Point would.
   
   Consequently, due to an abundance of caution, the password access for the node owner was added.