The device is broken until the next release. The LEDs are currently not
working (fixed in current OpenWRT master).

Also give a brief explanation about the BROKEN status being dependent on
the WiFi chip used and not the SoC family in general.

renamed by 210d97c5

was marked as broken by #1526 cause of #1505

the tag was added by dd23a805

When two domains alias the same name (or one aliases another), display a
meaningful error message like:

    Failed to alias domain 'foo' as 'bar', name already taken by
    domain 'baz'.

The amount of local wifi clients is currently counted by two different
ways:

* asking the kernel wifi layer for the number of of clients on 2.4GHz and
  5GHz band
* asking batman-adv for the number of non-timed out entries in the local
  translation table with WiFi flag

The number of wifi24+wifi5 and the number of TT wifi client counts are
reported via respondd to various consumers. The ffrgb meshviewer is
displaying these values as:

* 2,4 GHz: wifi24
* 5 GHz: wifi5
* other: (TT local wifi+non-wifi clients) - (wifi24 + wifi5)

But the local translation table is holding entries much longer than the
wifi layer. It can therefore easily happen that a wifi client disappears in
the kernel wifi layer and batman-adv still has the entry stored in the
local TT.

The ffrgb meshviewer would then show this count in the category "other".
This often results in confusions because "other" is usually for ethernet
clients. And nodes with a frequently disappearing larger group of clients
(near bus stations or larger intersections) often show most clients under
the group "other" even when this devices doesn't have a LAN ethernet port.

It is better for presentation to calculate the number of total wifi clients
by summing up wifi24 + wifi5. And getting the number of total clients (non
wifi + wifi) by adding the result of the previous calculation to the sum of
non-wifi client in the local batman-adv translation table.

Fixes: 89a9d813 ("gluon-mesh-batman-adv-core: Announce client count by frequency")
Reported-by: Pascal Wettin <p.wettin@gmx.de>

- A Picostation M5 never existed
- TL-WR710N v1 and v2.1 are part of ar71xx-generic not ar71xx-tiny

patches/openwrt: refresh 0006-generic-vxlan-backport-support-for-VXLAN-over-link-local-IPv6-to-4.9.patch (#1663)

8de93ce745 mt76: update to the latest version
85cb473f93 mac80211: add a fix to prevent unsafe queue wake calls during restart
08db9397c9 mac80211: backport tx queue start/stop fix
810ee3b84a kernel: bump 4.14 to 4.14.104
5183df0dbf kernel: bump 4.9 to 4.9.161
eea538204b kernel: fix refcnt leak in LED netdev trigger on interface rename
f1803e3492 oxnas: add SoC restart driver for reboot
1bfe1ce5c4 oxnas: cheery-pick DTS improvements from master
9ee8c8daf4 kernel: bump 4.14 to 4.14.103
e2ba7a4b47 kernel: bump 4.9 to 4.9.160

Compile-tested: ramips-mt7621, ar71xx-generic

If no mcast_rate is set for the wifi-iface then there is no rate_idx (0)
set for the bss. This breaks for example 5GHz meshpoint interfaces because
0 maps to a CCK rate (11Mbit/s).

It must also be avoided that the ath10k-ct internal state for the rates is
not synced with the mac80211 rates state. Otherwise, the user specified
rate (e.g. a wifi-iface mcast_rate for a meshpoint interface) will only be
set on startup. And a short while after that, ath10k-ct specific code in
ath10k_check_apply_special_rates is missing a valid rate in its own
structures and is then recalculating a new default rate. This default rate
is in most situations not the requested rate.

Fixes: a399b607 ("ath10k/ath10k-ct: support multicast and management rate control")

5de163d67 vallumd: bump to 0.1.4
b8c2c2b1b mosquitto: update to 1.5.7
8a2d56684 irssi: update to 1.2.0
d0f5ae180 [18.06] python3: fix [CVE-2018-20406]
dad217d34 shadowsocks-libev: flush ss rules on entry
bbc2e68ed mosquitto: bump to 1.5.6
9ffcfea19 mariadb: bump to 10.1.38
09b794ecc stubby: update to version 0.2.4
41c4f82f8 stubby: Remove iamperson347 from maintainer
2cf2210d8 stubby: add Jonathan Underwood as co-maintainer (#7307)
709a73604 stubby: add reload_config to documentation
aa8380721 stubby: fix loading of config file
6e2451dd0 stubby: add uci support to init file
7a2b9df89 stubby: bump PKG_RELEASE
304596d21 stubby: remove unnecessary core limit
fd8505f76 stubby: add SPKI pin set for Cloudflare cert
b77053d35 stubby: add Cloudflare 1.0.0.1 and ::1001 servers
3f17c54f2 stubby: use EDNS client-subnet privacy by default
935126632 stubby: fix config file definition
d3b090a31 stubby: rearrange Makefile for clarity
a3a73ef7b stubby: add missing dependency on ca-certificates
ccf0c71ac getdns: update to version 1.5.0
07e647645 getdns: Remove iamperson347 from maintainer
ca7555e52 getdns: fix missing libbsd dependency
cc8439566 acme: Fix loading credentials
fb3dd71ef youtube-dl: update to version 2019.01.30.1
4368783e9 python-idna: Add missing dependency on python(3)-codecs
480e4d7e8 python/python3: Fix lib2to3 fixes search
02dd97d14 libsndfile: update to 42132c543358cee9f7c3e9e9b15bb6c1063a608e
34dec8190 python3: backport CVE-2018-14647 patch from upstream [18.06]
3785db429 python: backport CVE-2018-14647 patches from upstream [18.06]
8f41fa7f8 nut: Default to run as root but fix alt runas
f7048b725 libsndfile: update to 8ddc442d539ca775d80cdbc7af17a718634a743f a/ulaw: fix multiple buffer overflows
e3f32b75b python/python3: fix .dist-info missing for setuptools and pip

Compile-tested: ramips-mt7621, ar71xx-generic

1be6ff6dc0 kernel: bump 4.14 to 4.14.102
e9cb40caa4 kernel: bump 4.9 to 4.9.159
d32bbd7477 mac80211: brcmfmac: backport 5.0 & 5.1 important changes/fixes
ce3a53c4f6 dnsmasq: prefer localuse over resolvfile guesswork
87fb8aea87 dnsmasq: allow using dnsmasq as the sole resolver
405840631c build: Accept BIN_DIR parameter for legacy-images
bc3eb970ab ar71xx: Fix 5 GHz MAC address for Archer C60 v2
20f1b7d3f5 kernel: bump 4.14 4.14.101
d669be4654 kernel: bump 4.9 to 4.9.158

Compile-tested: ramips-mt7621, ar71xx-generic
Runtime-tested: ramips-mt7621 (D-Link DIR860L B1)

62feabecd8 kernel: bump 4.14 to 4.14.99
9fb3710a8b kernel: bump 4.9 to 4.9.156
e5ace80759 mt76: update to the latest version
fbb2186fbd kernel: bump 4.14 to 4.14.98
72870cc108 kernel: bump 4.9 to 4.9.155
19a6c4b2b3 mac80211: brcmfmac: fix a possible NULL pointer dereference
d997712c71 ath9k: register GPIO chip for OF targets

Compile-tested: ipq40xx, ramips-mt7621
Runtime-tested: none

This package allows to automatically switch to another domain, either
at a given point in time or after the node was offline long enough.

This reverts commit b92e4044.

Committing in this case is unnecessary as that job is already handled by 998-commit
which is in a superior position to commit, as it is run after all relevant changes to
the configuration have been made.

Gluon has multiple ways to obtain unique MAC-addresses. They are either
provided by the WiFi driver or derived from the primary MAC-address.

Quoting the same file:

> It's necessary that the first 45 bits of the MAC address don't
> vary on a single hardware interface, since some chips are using
> a hardware MAC filter. (e.g 'rt305x')

This currently fails in case the rt35xx based chips mac address differs
from the primary MAC. In this case, the MAC address for the client0 radio
(vif 1) comes from the WiFi driver. As there is only a single
MAC-address provided by '/sys/class/ieee80211/phyX/addresses' but the
MAC-address for mesh 0 (vif 2) is derived from the Node-ID, resulting in
different first 45 bits. The WiFi won't come up altogether in this case.

This commit verifies at least 4 MAC-Addresses are provided by the WiFi
driver. If this is not the case, all MAC-addresses are derived from the
primary MAC. This way, affected radios are working correctly.

Drivers with software rate control can directly use the selected multicast
rate for multicast/broadcast frames and the minimal basic rate for
management frames. But drivers with offloaded rate control algorithms must
be informed about such upper layer decisions to configure the
hardware/firmware.

A new BSS_CHANGED_MCAST_RATE is introduced in mac80211 to automatically
inform all drivers. ath10k can detect this event and forward it via WMI to
the driver. The already existing BSS_CHANGED_BASIC_RATES can be used to
select the management rate.

Without the WMI commands, a low rate (not necessarily one from the basic
rates) is used for bcast/mcast/management frames. This means that the
/etc/config/wireless settings basic_rate and mcast_rate would have no
effect on the rates selected by this driver for the mentioned frames.

This backports the TP-Link Archer C50 v4.

We are dropping the following upstream commits. They add support for the
TP-Link recovery-flag which enabled the web-recovery. As they are not
needed for the router to work, we drop them for now.

28cd2ca base-files: sysupgrade: support additional mtd options
1e06482 mtd: add logic for TP-Link ramips recovery magic

also added manifest aliases for gl-ar150, gl-ar300m, gl-ar750

This allows for smaller firmware images and makes it possible to reset a
device via firstboot command.

Signed-off-by: Matthias Fritzsche <matthias@chemnitz.freifunk.net>