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

@@ -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

@@ -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

@@ -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.openwrt.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

@@ -225,7 +225,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

@@ -40,7 +40,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.2.rst

@@ -46,7 +46,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.3.rst

@@ -17,7 +17,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.4.rst

@@ -18,7 +18,7 @@ Bugfixes
 * Fix unintended difference between autoupdater version comparison and dpkg/opkg
 
   Alphanumeric characters were considered less than end-of-string, when the
-  intended bahaviour (as implemented by dpkg and opkg) is that only ``~`` is
+  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``
@@ -35,7 +35,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.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*.
@@ -389,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>`_)
 

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.

docs/releases/v2018.2.2.rst

+Gluon 2018.2.2
+==============
+
+Removed hardware support
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Support for the Onion Omega has been removed since the device does not
+have an ethernet port, and even with the ethernet shield connected the
+interface would not have been configured.
+
+Bugfixes
+~~~~~~~~
+
+* Fixes vulnerabilities that allowed for remote crashes and denial of service attacks through the Linux kernels
+  TCP selective acknowledgement implementation. (CVE-2019-11477, CVE-2019-11478 and CVE-2019-11479)
+
+* Fixes a bug in the image generation for the Netgear R6120 where the OverlayFS might not be created on boot as
+  the JFFS2 end-of-filesystem marker was omitted by the vendor firmware. This resulted in the router not being
+  able to save its configuration and seemingly "being stuck" in config-mode. (`#1722 <https://github.com/freifunk-gluon/gluon/pull/1722>`_)
+
+* Fixes oddities in the calculation of non-wireless clients published through respondd on batman-adv networks.
+  Previously both the kernel wifi layer and batman-adv were consulted, which led to issues because they use 
+  different timeout values. (`#1676 <https://github.com/freifunk-gluon/gluon/pull/1676>`_)
+
+* Fixes doubled batman-adv management overhead, introduced with Gluon v2017.1. A timer in batman-adv was
+  wrongly started twice, resulting in each node emitting not one but two OGMs from the same originator per 5 seconds.
+  (`#1446 <https://github.com/freifunk-gluon/gluon/issues/1446>`_)
+
+* Fixes an issue, where services provided by a node (such as DNS resolver or status-page)
+  might become unavailable due to other misbehaving nodes on the same layer 2 segment.
+  (`#1659 <https://github.com/freifunk-gluon/gluon/issues/1659>`_)
+
+* Fixes traffic shaping not working correctly when using tunneldigger, as well as the migration between fastd 
+  and tunneldigger (`#1736 <https://github.com/freifunk-gluon/gluon/issues/1736>`_)
+
+
+Other changes
+~~~~~~~~~~~~~
+
+* Linux kernel has been updated to 4.9.182 or 4.14.128, depending on the target
+
+
+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.