docs/releases/v2016.2.4.rst

@@ -48,7 +48,7 @@ Known Issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2016.2.5.rst

@@ -29,7 +29,7 @@ Known Issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2016.2.6.rst

@@ -13,7 +13,7 @@ Bugfixes
 ~~~~~~~~
 
 * Fix `CVE-2016-10229 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10229>`_
-  (`#1097 <https://github.com/freifunk-gluon/gluon/issues/1097>`_)
+  (`#1097 <https://github.com/freifunk-gluon/gluon/pull/1097>`_)
 
   Fortunately, the standard Gluon setup is not vulnerable, as the issue only affects
   applications that use MSG_PEEK on UDP sockets. dnsmasq does use MSG_PEEK, but
@@ -50,7 +50,7 @@ Known Issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2016.2.7.rst

@@ -24,7 +24,7 @@ Known Issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2016.2.rst

@@ -64,13 +64,13 @@ New features
 * batman-adv: mesh_no_rebroadcast is now enabled for Mesh-on-WAN/LAN (`#652 <https://github.com/freifunk-gluon/gluon/issues/652>`_)
 
 * The new UCI option ``gluon-core.@wireless[0].preserve_channels`` can be used to
-  prevent a changed WLAN channel from being reset on firmware upgrades (`#640 <https://github.com/freifunk-gluon/gluon/issues/640>`_)
+  prevent a changed WLAN channel from being reset on firmware upgrades (`#640 <https://github.com/freifunk-gluon/gluon/pull/640>`_)
 
 * PoE passthrough can now be configured from site.conf and the Advanced Settings
   on TP-Link CPE 210/510 and Ubiquiti NanoStations (`#328 <https://github.com/freifunk-gluon/gluon/issues/328>`_)
 
 * The config mode *altitude* field can now be hidden using the ``config_mode.geo_location.show_altitude``
-  site.conf setting (`#693 <https://github.com/freifunk-gluon/gluon/issues/693>`_)
+  site.conf setting (`#693 <https://github.com/freifunk-gluon/gluon/pull/693>`_)
 
 * The contact information field in the config mode can be made obligatory using
   the ``config_mode.owner.obligatory`` site.conf option
@@ -93,7 +93,7 @@ New features
   802.11b rates (`#810 <https://github.com/freifunk-gluon/gluon/pull/810>`_)
 
 * ath10k-based devices are now supported officially; it's possible to choose between
-  IBSS- and 11s-capable firmwares in site.mk (`#864 <https://github.com/freifunk-gluon/gluon/pull/864>`_)
+  IBSS- and 11s-capable firmwares in site.mk (`#864 <https://github.com/freifunk-gluon/gluon/issues/864>`_)
 
 * The ``prefix4`` and ``next_node.ip4`` site.conf options are optional now.
 
@@ -106,7 +106,7 @@ Bugfixes
   mac80211, hostapd and other related drivers and services have been backported from LEDE ``42f559e``.
 
 * Extremely slow downloads could lead to multiple instances of the autoupdater
-  running concurrently (`#582 <https://github.com/freifunk-gluon/gluon/pull/582>`_)
+  running concurrently (`#582 <https://github.com/freifunk-gluon/gluon/issues/582>`_)
 
   A lockfile is used to prevent this and timeouts have been added to download processes.
 
@@ -172,7 +172,7 @@ Known Issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.1.rst

@@ -34,7 +34,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.2.rst

@@ -12,7 +12,7 @@ New features
   preserved on upgrades.
 
 * Allow configuring the batman-adv routing algorithm (*BATMAN IV* or *BATMAN V*)
-  in *site.conf* (`#1185 <https://github.com/freifunk-gluon/gluon/issues/1185>`_)
+  in *site.conf* (`#1185 <https://github.com/freifunk-gluon/gluon/pull/1185>`_)
 
   *BATMAN V* still hasn't received extensive testing (and is incompatible with *BATMAN IV*).
   This new option allows to set up *BATMAN V*-based test meshes. If unset, the routing
@@ -55,7 +55,7 @@ Bugfixes
   fixed, triggering a reboot instead.
 
 * Also display *gluon-config-mode:novpn* message when Tunneldigger is installed, but disabled
-  (`#1172 <https://github.com/freifunk-gluon/gluon/issues/1172>`_)
+  (`#1172 <https://github.com/freifunk-gluon/gluon/pull/1172>`_)
 
   It was only displayed on nodes with fastd before.
 
@@ -71,7 +71,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.3.rst

@@ -14,7 +14,7 @@ Bugfixes
   CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 and
   2017-CVE-14496
 
-  While many of the most severe (remote code execution) vulnarabilities are in
+  While many of the most severe (remote code execution) vulnerabilities are in
   the DHCP component of dnsmasq, which is not active on a Gluon node unless in
   Config Mode, CVE-2017-14491 does affect us. An attacker can cause memory
   corruption and possibly remote code execution by deploying a malicious DNS
@@ -26,7 +26,7 @@ Bugfixes
   of the Gluon build, including tcpdump, curl and mbedtls
 
   Please refer to the
-  `LEDE commit log <https://git.lede-project.org/?p=source.git;a=shortlog;h=refs/heads/lede-17.01>`_
+  `LEDE commit log <https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/lede-17.01>`_
   for details.
 
 * Filtering of multicast packets between the mesh and the *local-node* interface
@@ -52,7 +52,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.4.rst

@@ -43,7 +43,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.5.rst

@@ -41,7 +41,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.6.rst

@@ -81,7 +81,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.7.rst

@@ -24,7 +24,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.8.rst

@@ -36,7 +36,7 @@ Bugfixes
   and a number of other minor issues)
 
   The listed bugs could lead to high rates of batman-adv management traffic
-  (causing considerable load), trigger warnings about packet checksum failues
+  (causing considerable load), trigger warnings about packet checksum failures
   in certain non-standard interface configurations, and possibly other issues.
 
 
@@ -61,7 +61,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2017.1.rst

@@ -83,13 +83,15 @@ New features
 ~~~~~~~~~~~~
 
 * Localization support has been added to the status page. In addition to German,
-  there are English and Russian translations now (`#1044 <https://github.com/freifunk-gluon/gluon/issues/1044>`_)
+  there are English and Russian translations now (`#1044 <https://github.com/freifunk-gluon/gluon/pull/1044>`_)
 
 * Add support for making nodes a DNS cache for clients
-  (`#1000 <https://github.com/freifunk-gluon/gluon/issues/1000>`_)
+  (`#1000 <https://github.com/freifunk-gluon/gluon/pull/1000>`_)
+
+  See also: :doc:`../features/dns-cache`
 
 * Add L2TP via tunneldigger as an alternative VPN system
-  (`#978 <https://github.com/freifunk-gluon/gluon/issues/978>`_)
+  (`#978 <https://github.com/freifunk-gluon/gluon/pull/978>`_)
 
   L2TP will usually give better performance than fastd as it runs in kernel
   space, but it does not provide encryption. Also, tunneling over IPv6 is
@@ -98,7 +100,7 @@ New features
   It is not possible to include both fastd and tunneldigger in the same
   firmware.
 
-* Add source filter package (`#1015 <https://github.com/freifunk-gluon/gluon/issues/1015>`_)
+* Add source filter package (`#1015 <https://github.com/freifunk-gluon/gluon/pull/1015>`_)
 
   The new package *gluon-ebtables-source-filter* can be used to prevent traffic
   using unexpected IP addresses or packet types from entering the mesh.
@@ -184,7 +186,7 @@ Internals
 ~~~~~~~~~
 
 * The LuCI base libraries have been replaced by a stripped-down
-  version called "gluon-web" (`#1007 <https://github.com/freifunk-gluon/gluon/issues/1007>`_)
+  version called "gluon-web" (`#1007 <https://github.com/freifunk-gluon/gluon/pull/1007>`_)
 
   Custom packages will need to be adjusted; in particular, all uses of *luci.model.uci*
   need to be replaced with *simple-uci*. The Gluon documentation explains the most important
@@ -225,7 +227,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 

docs/releases/v2018.1.1.rst

+Gluon 2018.1.1
+==============
+
+Bugfixes
+~~~~~~~~
+
+* Fix a bug leading to configuration loss on upgrade under certain circumstances
+  (`#1496 <https://github.com/freifunk-gluon/gluon/issues/1496>`_)
+
+  The issue can only occur when upgrading from 2018.1 and there are multiple
+  mirror entries in *site.conf* (specifically, an early failure for one of the
+  mirrors, e.g. during DNS resolution, followed by a successful upgrade from a
+  different mirror triggers the issue).
+
+  This is a regression in Gluon 2018.1.
+
+* Fix next-node ARP issue
+  (`#1488 <https://github.com/freifunk-gluon/gluon/issues/1488>`_)
+
+  A routing table issue led to ARP requests being sent from the next-node IPv4 address, but with
+  a node-specific source MAC address. This could make the next-node IPv4 address unreachable.
+
+  This is a regression in Gluon 2018.1.
+
+* Fix build on hosts with glibc 2.28
+
+  Fixed by various tool upgrades in LEDE (*bison*, *e2fsutils*, ...)
+
+Other changes
+~~~~~~~~~~~~~
+
+* Linux kernel has been updated to v4.4.148
+
+Known issues
+~~~~~~~~~~~~
+
+* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
+
+  Reducing the TX power in the Advanced Settings is recommended.
+
+* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
+
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
+
+* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
+
+  The current API is inconsistent and will be replaced eventually. The old API will still be supported for a while.
+
+* Frequent reboots due to out-of-memory or high load due to memory pressure on weak hardware specially in larger meshes
+  (`#1243 <https://github.com/freifunk-gluon/gluon/issues/1243>`_)
+
+  Optimizations in Gluon 2018.1 have significantly improved memory usage.
+  There are still known bugs leading to unreasonably high load that we hope to
+  solve in future releases.

docs/releases/v2018.1.2.rst

+Gluon 2018.1.2
+==============
+
+Bugfixes
+~~~~~~~~
+
+* Fix a bug leading to missing IPv6 addresses in respondd announcements
+  (`#1523 <https://github.com/freifunk-gluon/gluon/issues/1523>`_)
+
+  The pattern that was used to match addresses from /proc/net/if_inet6
+  did not expect interface indexes growing past two characters.
+
+* Mark ipq806x target as broken for unstable client WiFi
+  (`#1505 <https://github.com/freifunk-gluon/gluon/issues/1505>`_)
+
+  Station connections to the QCA9880 radio on the TP-Link C2600s are frequently
+  disconnected, leading to an abysmal user experience.
+
+* Fix button behaviour on FRITZ!Box 4020
+  (`#1544 <https://github.com/freifunk-gluon/gluon/pull/1544>`_)
+
+  Buttons were triggering an instant reboot into config mode, fix by setting
+  buttons to active low instead of active high.
+
+* Prevent caching of redirects on config mode and status page
+  (`#1530 <https://github.com/freifunk-gluon/gluon/issues/1530>`_)
+
+  As the path to both config mode and status page were changed between versions
+  users could be affected by a redirect to a no more valid URL. 
+
+* batman-adv has received two bugfixes, which were `backported <https://github.com/openwrt/routing/commit/7bf62cc8b556b5046f9bbd37687376fe9ea175bb>`_ from v2018.4
+
+Other changes
+~~~~~~~~~~~~~
+
+* Linux kernel has been updated to v4.4.153
+
+Known issues
+~~~~~~~~~~~~
+
+* Missing kernel module dependencies prevent batman-adv from being loaded on devices without WiFi drivers  (`#1578 <https://github.com/freifunk-gluon/gluon/issues/1578>`_)
+
+* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
+
+  Reducing the TX power in the Advanced Settings is recommended.
+
+* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
+
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
+
+* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
+
+  The current API is inconsistent and will be replaced eventually. The old API will still be supported for a while.
+
+* Frequent reboots due to out-of-memory or high load due to memory pressure on weak hardware specially in larger meshes
+  (`#1243 <https://github.com/freifunk-gluon/gluon/issues/1243>`_)
+
+  Optimizations in Gluon 2018.1 have significantly improved memory usage.
+  There are still known bugs leading to unreasonably high load that we hope to
+  solve in future releases.

docs/releases/v2018.1.3.rst

+Gluon 2018.1.3
+==============
+
+Bugfixes
+~~~~~~~~
+
+* Fix kernel module dependency collection for external modules (`#1580 <https://github.com/freifunk-gluon/gluon/pull/1580>`_)
+
+  A regression in v2018.1.2 prevented the batman-adv kmod from being loaded on devices without WiFi drivers.
+
+Known issues
+~~~~~~~~~~~~
+
+* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
+
+  Reducing the TX power in the Advanced Settings is recommended.
+
+* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
+
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
+
+* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
+
+  The current API is inconsistent and will be replaced eventually. The old API will still be supported for a while.
+
+* Frequent reboots due to out-of-memory or high load due to memory pressure on weak hardware specially in larger meshes
+  (`#1243 <https://github.com/freifunk-gluon/gluon/issues/1243>`_)
+
+  Optimizations in Gluon 2018.1 have significantly improved memory usage.
+  There are still known bugs leading to unreasonably high load that we hope to
+  solve in future releases.

docs/releases/v2018.1.4.rst

+Gluon 2018.1.4
+==============
+
+Bugfixes
+~~~~~~~~
+
+* Fix regression in autoupdater version comparison function
+
+  Due to a regression in Gluon 2018.1, the autoupdater would incorrectly
+  consider certain version strings equal and not attempt to upgrade.
+  In particular, any string and its prefix were considered equal when the
+  prefix did not end with a digit. For example, the following relations were
+  not evaluated correctly:
+
+  * ``1.0`` < ``1.0.1``
+  * ``1.0~pre`` < ``1.0``
+
+* Fix unintended difference between autoupdater version comparison and dpkg/opkg
+
+  Alphanumeric characters were considered less than end-of-string, when the
+  intended behaviour (as implemented by dpkg and opkg) is that only ``~`` is
+  less than end-of-string. This broke relations like the following:
+
+  * ``1.0`` < ``1.0a``
+  * ``1.0a`` < ``1.0ab``
+  * ``1.0a`` < ``1.0a1``
+
+
+Known issues
+~~~~~~~~~~~~
+
+* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
+
+  Reducing the TX power in the Advanced Settings is recommended.
+
+* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
+
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
+
+* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
+
+  The current API is inconsistent and will be replaced eventually. The old API will still be supported for a while.
+
+* Frequent reboots due to out-of-memory or high load due to memory pressure on weak hardware specially in larger meshes
+  (`#1243 <https://github.com/freifunk-gluon/gluon/issues/1243>`_)
+
+  Optimizations in Gluon 2018.1 have significantly improved memory usage.
+  There are still known bugs leading to unreasonably high load that we hope to
+  solve in future releases.

docs/releases/v2018.1.rst

@@ -150,7 +150,7 @@ anymore.
 Filtering IGMP/MLD queries directed towards the mesh ensures that each node becomes the multicast querier
 for its own clients (unless there are other multicast-aware switches connected to the node), rather
 than electing a single, basically arbitrary node in the mesh to become the querier. Overall,
-this should significantly improve the reliablity of multicast in the mesh. This is especially
+this should significantly improve the reliability of multicast in the mesh. This is especially
 important for IPv6, as the IPv6 Neighbour Discovery Protocol (NDP) is based on local multicast.
 
 See also the documentation of the :ref:`site.conf mesh section <user-site-mesh>`.
@@ -176,7 +176,7 @@ Public key in respondd data (optional)
 ======================================
 
 If desired, the fastd public key of a node can be included in the respondd nodeinfo data,
-faciliating the correlations of VPN peers and nodes. As the VPN key is transmitted unencrypted
+facilitating the correlations of VPN peers and nodes. As the VPN key is transmitted unencrypted
 in the fastd handshake, this would theoretically allow an ISP to determine which nodes
 are operated behind which internet line. Therefore, this feature must be enabled explicitly
 by setting *mesh_vpn.pubkey_privacy* to ``false`` in *site.conf*.
@@ -207,6 +207,7 @@ site.mk
 * We recommend to use *GLUON_FEATURES* for all Gluon packages, and rely on
   *GLUON_SITE_PACKAGES* for non-Gluon (OpenWrt) packages only, as explained
   in :ref:`user-site-feature-flags`.
+* The `GLUON_ATH10K_MESH` variable was renamed to `GLUON_WLAN_MESH`.
 
 site.conf
 =========
@@ -388,7 +389,7 @@ Known issues
 
 * The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
 
-  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
+  This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
 
 * Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
 
@@ -400,3 +401,21 @@ Known issues
   Optimizations in Gluon 2018.1 have significantly improved memory usage.
   There are still known bugs leading to unreasonably high load that we hope to
   solve in future releases.
+
+* Configuration loss on upgrade under certain circumstances
+  (`#1496 <https://github.com/freifunk-gluon/gluon/issues/1496>`_)
+
+  The issue can only occur when upgrading from 2018.1 and there are multiple
+  mirror entries in *site.conf* (specifically, an early failure for one of the
+  mirrors, e.g. during DNS resolution, followed by a successful upgrade from a
+  different mirror triggers the issue).
+
+  This is a regression in Gluon 2018.1.
+
+* Next-node ARP issue
+  (`#1488 <https://github.com/freifunk-gluon/gluon/issues/1488>`_)
+
+  A routing table issue leads to ARP requests being sent from the next-node IPv4 address, but with
+  a node-specific source MAC address. This can make the next-node IPv4 address unreachable.
+
+  This is a regression in Gluon 2018.1.

docs/releases/v2018.2.1.rst

+Gluon 2018.2.1
+==============
+
+Added hardware support
+~~~~~~~~~~~~~~~~~~~~~~
+
+ar71xx-generic
+^^^^^^^^^^^^^^
+
+* AVM
+
+  - Fritz!WLAN Repeater 300E
+
+ramips-mt7620
+^^^^^^^^^^^^^
+
+* Nexx
+
+  - WT3020AD/F/H [#noibss]_
+
+ramips-mt76x8
+^^^^^^^^^^^^^
+
+* GL.iNet
+
+  - MT300N (v2) [#noibss]_
+
+* Netgear
+
+  - R6120 [#noibss]_
+
+* TP-Link
+
+  - Archer C50 (v3, v4) [#noibss]_
+  - TL-WR841N (v13) [#noibss]_
+
+.. [#noibss]
+  Device or target does not support AP+IBSS mode: This device or target will not be built
+  when *GLUON_WLAN_MESH* is set to ``ibss``.
+
+Bugfixes
+~~~~~~~~
+
+* Fixes a bug in the batman-adv respondd module that caused duplicate
+  IPv6 addresses in nodeinfo replies (`#1615 <https://github.com/freifunk-gluon/gluon/issues/1615>`_)
+
+  This was visible on the status page and several map implementations.
+  The new implementation uses netlink instead of parsing `/proc/net/if_inet6`.
+
+* Fixes a localization issue in gluon-config-mode-geo-location which
+  resulted in a partial translation of the wizard's location section
+  text. (`#1611 <https://github.com/freifunk-gluon/gluon/issues/1611>`_)
+
+* Fixes the display of the improved memory usage estimation in gluon-status-page
+
+  This change was actually already merged in time for v2018.2 but the
+  JavaScript was not rebuilt.
+
+* Fixes automatic updates for several devices by adding and updating
+  the autoupdater image names
+
+  This affects the following devices:
+
+  * GL.iNet GL-AR150
+  * GL.iNet GL-AR300M
+  * GL.iNet GL-AR750
+  * Raspberry Pi Model B+ Rev 1.2
+
+* Fixes the primary MAC address selection for Unifi AC
+  Lite/Mesh/Pro/Mesh Pro (`#1629 <https://github.com/freifunk-gluon/gluon/issues/1629>`_)
+
+* Fixes low data rate selection for multicast and management frames on
+  ath10k and ath10k-ct (`#1644 <https://github.com/freifunk-gluon/gluon/pull/1644>`_)
+
+  A patchset has been backported that notifies these drivers of requested data rate changes
+
+* Fixes the data rate selection in ath10k and ath10k-ct when no
+  `mcast_rate` is configured (`#1657 <https://github.com/freifunk-gluon/gluon/pull/1657>`_)
+
+  Previously a missing mcast_rate could result in broken 5 GHz connectivity
+
+New features
+~~~~~~~~~~~~
+
+Scheduled domain switch
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Gluon has support for multiple domains since its v2018.1 release.
+The scheduled domain switch allows for reliable migrations between
+domains at a preconfigured time.
+This can be useful for communities that, among other things, plan to
+
+  * migrate between IBSS and 802.11s
+  * activate VXLAN encapsulation on wired mesh links
+
+Improved frequency band distribution of dual-band radios
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A new algorithm that improves the distribution of dual-band radios was
+added. They will now be evenly distributed between the 2.4 and 5 GHz
+band, with a preference towards 2.4 GHz.
+
+If a device has only a single dual-band radio, like the AVM FRITZ!WLAN
+Repeater 300E, it will be configured for 2.4 GHz.
+
+Known issues
+~~~~~~~~~~~~
+
+* Default TX power on many Ubiquiti devices is too high, correct offsets are
+  unknown (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
+
+  Reducing the TX power in the Advanced Settings is recommended.
+
+* The MAC address of the WAN interface is modified even when Mesh-on-WAN is
+  disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
+
+  This may lead to issues in environments where a fixed MAC address is expected
+  (like VMware when promiscuous mode is disallowed).
+
+* Inconsistent respondd API
+  (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
+
+  The current API is inconsistent and will be replaced eventually. The old API
+  will still be supported for a while.
+
+* Frequent reboots due to out-of-memory or high load due to memory pressure on
+  weak hardware specially in larger meshes
+  (`#1243 <https://github.com/freifunk-gluon/gluon/issues/1243>`_)
+
+  Optimizations in Gluon 2018.1 have significantly improved memory usage.
+  There are still known bugs leading to unreasonably high load that we hope to
+  solve in future releases.