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.
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: 89a9d8138c ("gluon-mesh-batman-adv-core: Announce client count by frequency")
Reported-by: Pascal Wettin <p.wettin@gmx.de>
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: a399b60735 ("ath10k/ath10k-ct: support multicast and management rate control")
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 reverts commit b92e404437.
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
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>
6e16dd1234 mt76: update to the latest version
76037756d0 kernel: bump 4.14 to 4.14.94
455bfd1065 kernel: bump 4.9 to 4.9.151
fafd7691e6 opkg: update to latest Git head
e789bd2243 opkg: drop argument from check_signature in opkg.conf
3603c2321d ramips: mt7621: fix 5GHz WiFi LED on ZBT WG3526
7f98cd8d50 odhcpd: fix onlink IA check (FS#2060)
abd0f7995e kmod-sched-cake: bump to latest cake
Compile-tested: ar71xx-{tiny,generic}, ramips-mt7621, x86-64
