83 lines
3.8 KiB
ReStructuredText
83 lines
3.8 KiB
ReStructuredText
Gluon v2020.1.2
|
|
===============
|
|
|
|
Removed hardware support
|
|
------------------------
|
|
|
|
lantiq-xway
|
|
~~~~~~~~~~~
|
|
|
|
- AVM FRITZ!Box 7320 [#switchports_not_working]_
|
|
- AVM FRITZ!Box 7330 [#switchports_not_working]_
|
|
- AVM FRITZ!Box 7330 SL [#switchports_not_working]_
|
|
|
|
.. [#switchports_not_working]
|
|
The switchports on these devices are not working properly (`#1943 <https://github.com/freifunk-gluon/gluon/issues/1943>`_)
|
|
|
|
Bugfixes
|
|
--------
|
|
|
|
- Fixes a bug in the tunneldigger watchdog where the watchdog would incorrectly find itself while looking up the running tunneldigger process. It then went on and assumed a PID mismatch between the tunneldigger service and its PID file and therefore caused an unnecessary restart of the tunnel. (`#1952 <https://github.com/freifunk-gluon/gluon/issues/1952>`_)
|
|
|
|
- Fixes an oversight in the firewalling of the respondd service where queries from prefix listed in ``extra_prefixes6`` would be dropped. (`#1941 <https://github.com/freifunk-gluon/gluon/issues/1941>`_)
|
|
|
|
- Fixes a bug in ``gluon-web`` where forms would not correctly update their field visibility on reset. This affected, for example, the private wifi page in the config mode. (`#1970 <https://github.com/freifunk-gluon/gluon/pull/1970>`_)
|
|
|
|
- Fixes RX buffer sizing in the ath10k driver to allow for frames larger than 1528 Bytes. (`#1992 <https://github.com/freifunk-gluon/gluon/pull/1992>`_)
|
|
|
|
- Fixes a regression in the v4.14 kernel where spurious data bus errors on ar71xx devices would cause a reboot. (`#1994 <https://github.com/freifunk-gluon/gluon/pull/1994>`_)
|
|
|
|
|
|
Other changes
|
|
-------------
|
|
|
|
- Linux kernel has been updated to 4.14.176
|
|
|
|
|
|
Internals
|
|
---------
|
|
|
|
- OpenWrt 19.07 introduced the urgnd entropy daemon that serves the same function as the haveged service, which we have been recommending. To not have two redundant entropy daemons in this release we remove urngd in favor of haveged in the v2020.1 release series.
|
|
|
|
Known issues
|
|
------------
|
|
|
|
- High chance of ending in a soft-bricked state for Ubiquiti EdgeRouter-X. Workaround is to
|
|
repeat initial installation using the serial console. (`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
|
|
|
|
- Out of memory situations with high client count on ath9k.
|
|
(`#1768 <https://github.com/freifunk-gluon/gluon/issues/1768>`_)
|
|
|
|
- The integration of the BATMAN_V routing algorithm is incomplete.
|
|
|
|
- | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/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 <https://github.com/freifunk-gluon/gluon/issues/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 <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 especially 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.
|
|
|