With the new role-based interface configuration, it would be better to
rename the wan/wan6 interfaces to uplink/uplink6, but that would cause
unnecessary churn for the firewall configuration, so it is left for a
later update.
As all interfaces with the 'uplink' role are in the br-wan bridge, it is
not possible to assign these to the 'mesh' role independently - instead,
br-wan is added as a mesh interface as soon as a single interface has
both the 'uplink' and 'mesh' roles. The UCI section for this
configuration is now called 'mesh_uplink' instead of 'mesh_wan'.
For all interfaces that have the 'mesh', but not the 'uplink' role a
second configuration 'mesh_other' is created. If there is more than one
such interface, all these interfaces are bridged as well (creating a
bridge 'br-mesh_other'). This replaces the 'mesh_lan' section with its
optional 'br-mesh_lan' bridge, but can also include interfaces that were
not considered "LAN" when interfaces roles are modified (via site.conf
or manually).
This copies the code from web-admin and uses it to create a neat
cli-accessible summary about a node
This could also be extended or possibly have all the data the status
page has
Co-Authored-By: Matthias Schiffer <mschiffer@universe-factory.net>
The 'hwmode' setting has been replaced with 'band' in OpenWrt to add
support for newer bands outside of 2.4G and 5G. Adjust Gluon accordingly.
[Matthias Schiffer: rebased, extended commit message]
The PHY lookup helper "find_phy_by_path" could not lookup the PHY name
for paths from multi-phy devices.
An example for such a path would be:
'1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
The integer after the plus (+) character determines the PHY index of the
specific device in relation to the PHY with the lowest index of the
device.
For example, if the device provides phy2 and phy3, the above path would
describe phy3. In case the device provides phy0 and phy1, it would
describe phy1.
Rewrite the "find_phy_by_path" function to support those paths as well
as regular device paths in a universal manner.
Signed-off-by: David Bauer <mail@david-bauer.net>
VoCores aren't exactly useful mesh nodes except for experimentation.
They certainly aren't worth maintaining a whole target, in particular
one that has a WLAN driver not used by any other target.
The file_contains_line helper function was not testing whether a file
exists or not prior attempting to read from it.
Add this check to circumvent errors on the private WiFi config in
case the hwflags file is missing.
Reported-by: Tom Herbers <freifunk@tomherbers.de>
Tested-by: Tom Herbers <freifunk@tomherbers.de>
Signed-off-by: David Bauer <mail@david-bauer.net>
This will hide the outdoor mode setting on compatible devices in case
the defined channels should be preserved.
Otherwise a user might be under the impression their device is compliant
with outdoor operation when in reality it still uses prohibited
channels.
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.
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
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.
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.
