From ed3cb1f541353a05d795bf2a899d3c85872aa512 Mon Sep 17 00:00:00 2001
From: Matthias Schiffer <mschiffer@universe-factory.net>
Date: Sun, 26 Aug 2018 13:31:25 +0200
Subject: [PATCH] docs: add v2018.1.1 release notes

---
 docs/index.rst              |  1 +
 docs/releases/v2018.1.1.rst | 54 +++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)
 create mode 100644 docs/releases/v2018.1.1.rst

diff --git a/docs/index.rst b/docs/index.rst
index b4e977934c..5f6869a482 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -70,6 +70,7 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
    :caption: Releases
    :maxdepth: 1
 
+   releases/v2018.1.1
    releases/v2018.1
    releases/v2017.1.8
    releases/v2017.1.7
diff --git a/docs/releases/v2018.1.1.rst b/docs/releases/v2018.1.1.rst
new file mode 100644
index 0000000000..0b15aeaa20
--- /dev/null
+++ b/docs/releases/v2018.1.1.rst
@@ -0,0 +1,54 @@
+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 promicious 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.