You are here
AREDN v3.20.3.0 is Available
AREDN Release Notes v3.20.3.0 – 27 March 2020
The AREDN team is pleased to announce the general availability of the latest stable release of AREDN firmware. We now fully support 70+ devices from four manufacturers. This diversity of supported equipment enables hams to choose the right gear for a given situation and budget.
AREDN firmware is now based on the most recent stable version of OpenWRT19.07.2 which was released in March 2020. This improvement is significant in that it enables AREDN firmware to benefit from the many bug fixes, security improvements and feature enhancements provided by OpenWRT developers from around the world.
The latest AREDN firmware contains features inherited from the newest OpenWRT upstream release (19.07.2). One important change is the inclusion of a new target (architecture) for the firmware, labelled “ath79”, which is the successor to the existing “ar71xx” targets. OpenWRT explains that their main goal for this target is to bring the code into a form that will allow all devices to run a standard unpatched Linux kernel. This will greatly reduce the amount of customization required and will streamline the firmware development process. As not all supported devices have been migrated to the new “ath79” target, AREDN continues to build firmware for both targets. You may notice that the AREDN download page has firmware for these two targets, and you should select the latest image based on the type of hardware (and the recommended target) on which it is to be installed.
Changes to the Supported Platform Matrix
Several devices are now shaded in light green to indicate that they are no longer recommended for AREDN firmware, primarily due to their low computing resources (memory/storage).
The following new devices are newly supported in the latest firmware release.
GL.iNet
Mikrotik
TP-LINK
Features added
-
Added /etc/board.json to aredn support data download #483 (ae6xe)
-
Added contact info/comment field for each tunnel connect… #479 (r1de)
-
Removed libopenssl (large library) and disable ssl in vtun #475 (dman776)
-
Updated with note regarding gl.inet keep settings #440 (dman776)
-
Enabled wan wifi client to connect to an open AP #434 (ae6xe)
-
Added first_boot field to indicate if this node has been configured #416 (dman776)
-
Fixed the consistency between “archive” and “realtime” SNR data #403 (mcleanra)
-
Updated .gitnignore to ignore more build artifacts #402 (BKasin)
Bugs fixed
-
Port Forward not working over dtdlink in LAN NAT mode #485 (ae6xe)
-
Fixed the Authentication for vtun to be compatible with legacy #478 (apcameron)
-
WAN interface fails to function on UBNT NS XM devices #433 (ae6xe)
-
Mesh Status missing owning host of service advertisement #421 (ae6xe)
-
Fixed call to getFrequency() to getFreq() in api #408 (r1de)
-
Added luasocket feed to make luasocket package available #391 (dman776)
Known issues
Please refer to https://github.com/aredn/aredn_ar71xx/issues for a list of outstanding defects.
Key workarounds
OLSR Restart
OLSR is the capability in AREDN that exchanges IP Addresses, Hostnames, and figures how to route packets across the mesh network. There continues to be an intermittent defect when OLSR starts as a device is powering up. OLSR fails to propagate or may miss receiving some hostname information. A one-time restart of OLSR will resolve the situation. This option can be found in Advanced Configuration settings--it doesn’t save a setting per se, rather restarts OLSR without rebooting the device.
How do I know when OLSR needs to be restarted:
-
IP Address is showing in Mesh Status: go to the IP Address’s node and restart OLSR
-
“Dtdlink” or “mid” is showing in a host name: go to those hosts and restart OLSR
-
Others can access a device by the hostname, but I can’t: restart OLSR on my device
PBE 400/400-ISO/620 degraded throughput over ethernet port
These Uniquiti PBE devices have a gigabit Ethernet port that does not handshake correctly with some switches. The device’s Ethernet port is locked to a 100mbps rate at Full-Duplex (still sufficient for the max rates generally achieved over RF). This made the port always functional, but for some switches the performance may be severely degraded. It is recommended to lock the rate on all switches this devices is connected to at the same 100mbps rate at Full-Duplex. Check your switch’s port statistics to determine if there are TX or RX packet errors. Alternatively, an iperf test from the node to another node on the same switch will identify if there is any performance degradation.
Upgrading Firmware Images
1) 32M RAM devices continue to be at the limit of available memory. This means that doing a sysupgrade to load new firmware may take many tries to succeed. Don't use these devices at hard to reach tower sites! The sysupgrade process needs close to 10M of memory to succeed.
Tips to get it to work:
i) fresh reboot and very quickly do the upgrade (recommended for all devices, particular if at a tower site)
ii) disable mesh RF and any use of wireless, reboot before sysupgrade
iii) disable or uninstall any packages that are running, e.g. meshchat
iv) as an almost last resort, scp the .bin image to /tmp on the node and from the command line type "sysupgrade -n <.bin filename>" (does not save settings)
v) as the last resort, tftp to load the factory image (does not save settings)
2) Do not count on being able to sysupgrade to return back to older AREDN images, when upgrading to ‘ath79’ target images. It might work, it might not based on if model names were cleaned up and changed moving to ath79. The older images may not be recognized on the newer target images. Do a tftp process instead.
3) To know what image to use, pay close attention to the table located here (scroll down): https://github.com/aredn/aredn_ar71xx .
AREDN® is a registered trademark of Amateur Radio Emergency Data Network, Inc.
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer