Gluon 2021.1.2

Important notes

This release fixes a critical security vulnerability in Gluon’s autoupdater.

Upgrades to v2021.1 and later releases are only supported from releases v2018.2 and later. Migration code for upgrades from older versions has been removed to simplify maintenance.


  • The Linux kernel was updated to version 4.14.275

  • The mac80211 wireless driver stack was updated to a version based on kernel 4.19.237

Various minor package updates are not listed here and can be found in the commit log.


  • [SECURITY] Autoupdater: Fix signature verification

    A recently discovered issue (CVE-2022-24884) in the ecdsautils package allows forgery of cryptographic signatures. This vulnerability can be exploited to create a manifest accepted by the autoupdater without knowledge of the signers’ private keys. By intercepting nodes’ connections to the update server, such a manifest allows to distribute malicious firmware updates.

    This is a critical vulnerability. All nodes with autoupdater must be updated. Requiring multiple signatures for an update does not mitigate the issue.

    As a temporary workaround, the issue can be mitigated on individual nodes by disabling the autoupdater via config mode or using the following commands:

    uci set autoupdater.settings.enabled=0
    uci commit autoupdater

    A fixed firmware should be installed manually before enabling the autoupdater again.

    See security advisory GHSA-qhcg-9ffp-78pw for further information on this vulnerability.

  • [SECURITY] Config Mode: Prevent Cross-Site Request Forgery (CSRF)

    The Config Mode was not validating the Origin header of POST requests. This allowed arbitrary websites to modify configuration (including SSH keys) on a Gluon node in Config Mode reachable from a user’s browser by sending POST requests with form data to

    The impact of this issue is considered low, as nodes are only vulnerable while in Config Mode.

  • Config Mode: Fix occasionally hanging page load after submitting the configuration wizard causing the reboot message and VPN key not to be displayed

  • Config Mode (OSM): Update default OpenLayers source URL

    The OSM feature of the Config Mode was broken when the default source URL was used for OpenLayers, as the old URL has become unavailable. The default was updated to a URL that should not become unavailable again.

  • Config Mode (OSM): Fix error when using " character in attribution text

  • respondd-module-airtime: Fix respondd crash on devices with disabled WLAN interfaces

    Several improvements were made to the error handling of the respondd-module-airtime package. The “PHY ID” field (introduced in Gluon 2021.1) was removed again.

  • ipq40xx: Fix bad WLAN performance on Plasma Cloud PA1200 and PA2200 devices

  • Fix occasional build failure in “perl” package with high number of threads (-j32 or higher)

Other improvements

  • Several improvements were made to the status page:

    • WLAN channel display does not require the respondd-module-airtime package anymore

    • The “gateway nexthop” label now links to the status page of the nexthop node

    • The timeout to retrieve information from neighbour nodes was increased, making the display of the name of overloaded, slow or otherwise badly reachable nodes more likely to succeed

Known issues

  • Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well. (#1937)

  • The integration of the BATMAN_V routing algorithm is incomplete.

    • Mesh neighbors don’t appear on the status page. (#1726) Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput metric.

    • Throughput values are not correctly acquired for different interface types. (#1728) This affects virtual interface types like bridges and VXLAN.

  • Default TX power on many Ubiquiti devices is too high, correct offsets are unknown (#94)

    Reducing the TX power in the Advanced Settings is recommended.

  • In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (#496)

    This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).