Separate wireless-related helper methods from the util module to a
new wireless module. This keeps them separated, as the amount of
wireless helpers increased in the past, justifying a separate module.
The netdev() lookup is confusing to use: whenever a interface does not
exist during boot (for example VLAN) or when the address is overridden
from board.json (which is not obvious at all), it will yield either no
address, or a different address than expected.
To avoid this confusion, using board.json-based interface() is
preferable. This converts all uses of netdev() to the corresponding
lan/wan lookups, except for the final fallback for eth0.
- Replace misnamed, closure-returning sysfs() to a reusable read() function
- Rename eth() to netdev(), pass full interface name
- Rename board() to interface()
- Split reuable get_netdev_addr() out of netdev()
gsub() returns the number of matches as its second return value. This
was unintendedly passed through by the util functions trim() and
node_id(). It can be presumed that this had no effect in practice, but
it can lead to surprising output when passing values to print() for
debugging.
This adds a helper method, which determines if the current platform
supports WPA3 or not.
WPA3 is supported if
- the device is not in the featureset category "tiny"
- the WiFi driver supports 802.11w management frame protection
Remove a lot of redundant code by switching to a match table listing
the targets and boards for each candidate for the primary MAC interface.
In addition, we add some flexiblity by allow to switch out the sysfs file
data source for the MAC address.
mac_to_ip() calculates an ipv6 address from a mac address according to
RFC 4291. For wireguard we have to use specially crafted addresses that
must be unique. This allows calculating such unique mac-based addresses
by allowing to optionally specifying the bytes to be inserted into the
address.
The is_outdoor function is placed inside the gluon.platform module, not
the platform_info module. Currently, the outdoor-mode wizard component
and the upgrade script fail due to nil-value calls.
Add the `wifi5.outdoor_chanlist` site configuration that
allows specifying an outdoor channel range that can be
switched to for regulatory compliance.
Upon enabling the outdoor option the device will
- configure the `outdoor_chanlist` on all 5 GHz radios
- which may enable DFS/TPC, based on the regulatory domain
- disable ibss/mesh on the 5 GHz radio, as DFS *will*
break mesh connections
- allow for htmode reconfiguration on 5 GHz radios
The outdoor option can be toggled from
- Advanced Settings
- W-LAN
- Outdoor Installation
The `preserve_channel` flag overrules the outdoor channel
selection.
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.
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.
