Triband radio support

[maurerle]

I'd like to reopen the changes from #1666 to make way to support #1661

This works quite well and exposes the three wifis correctly on the status-page:

radio0, 5GHz, 144 (client wifi)
radio1, 2.4GHz, 11 (client + mesh)
radio2, 5GHz, 44 (mesh)

and also the config mode shows the expected default config for such devices:

We might want to:

• grey out the mesh network operation if a radio does only support DFS channels (removed, as the site api does not directly support disabling items)
• adjust config to detect how wifis should be distributed best across the channels (similar to how it is done here

  gluon/package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless

  Line 15 in fc25b49

  -- First count all radios with a fixed frequency band.

  )
• move whole wireless configuration in uci to gluon.wireless in the future (far out of scope here)

This is currently focusing on having two 5GHz bands, where at least one does not support all channels.

[herbetom]

I think the mac address problem is as of now unresolved? #1666 (comment)

[maurerle]

To be honest, I did not really understand the problem with the MAC yet

I see that with 294b291 we add to the prior mac part if our counter overflows.
This seemed to work fine so I did not really understand what still has to be done about that

[T-X]

Would love to see the triband support! Devices with potential triband support and Gluon support I'm aware of: Plasmacloud PA2200 and the LibreRouter. Any other devices people would look forward to for triband support? Also, I guess this was untested with 6GHz so far? (I'd be looking forward to the Banana Pi BPI-R4, for instance, seems to have a dedicated phy for 6GHz for the WiFi7 iPA NIC module)

[maurerle]

I think @Djfe gave a quite extensive list of affected devices in #1661 (comment)

For now, this does not include 6GHz. I have some ideas to add counters to the 6g band as well, but this would create to much noise and untested code (and I am not to familiar with 6GHz frequencies) , so I think we should do this one at a time.

From the list of open todos, I think I can handle the first two eventually, but would definitely need help for a complete overhaul (I think this way stopping the old PR mainly?). If there is someone willing to draft something where I can built on, improve and test, I would be very happy :)

[herbetom]

@T-X Wifi 6E is probably another can of worms but relies on resolving the tripple radio problem #2906

@maurerle The mac address problem is from my understanding that we need more then the current 8 but this has to be carefully considered to not cause collisions (#2061, #1983). Just statically assigning more might not be the best approach

[maurerle]

There are concerns here regarding the probability of collision due to the reservation of the additional MAC addresses.
Steps to improve this are:

1. in batman-adv the mac address should be independent - should be checked: https://git.open-mesh.org/batman-adv.git/commit/5317331775c316
2. reconsider the assignment of mac addresses to avoid collisions
3. if we reserve more mac-addresses we have to see whether how we use them
   @neocturne

Regarding the assignment of the interfaces:
We don't need to solve this dynamically - write down the existing cases once (see all the triband devices)
and see if we have a solution for all cases.

[maurerle]

If the last mac-address byte was 254 then the next mac-addresses could overflow leading to something like:

root@ffac-lothringer-flomi:~# lua -e 'print(require("gluon.util").generate_mac(9))'
0a:a2:8d:fb:f9:102

One way to solve this is to zero more than 3 bits in
m6 = bit.band(m6, 0xF8) -- zero the last three bits (space needed for counting)
or just let the counter overflow.

See: af539fc

I think one can even remove the m6 = bit.band(m6, 0xF8) part now? @neocturne

[maurerle]

should be renamed to has_client_only_radio as this checks for a radio which can not be used for mesh

[maurerle]

At the last gluon meetup we discussed having a solution which suits the needs and is not to complex.
This currently distributes the devices as mesh and client across the radios and tries to respect incompatibilities.

A better approach would be to first count and evaluate all items and then decide what to do, as it is done for the multi band configuration:

gluon/package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless

Line 15 in fc25b49

-- First count all radios with a fixed frequency band.

Looking at the device list provided by @Djfe in #1661 (comment) I came to two possible operation modes:

a - there is 1 radio which supports only a subset of the channels while the other radio supports all unsupported channels (or more)
b - there are 2 radios with the same support channels, eventually with the same quality, eventually one radio would be preferred (though I neither know how to find the preference or set a preference to use the "better" one for mesh vs client 🤷 )

Devices	2.4GHz	5GHz	Preferred Usage
OpenMesh A62	1	2	a
Plasma Cloud PA2200	1	2	a
AVM Fritz!Repeater 3000 and 6000	1	2	a
AVM Fritz!Box 4060	-	no support
LibreRouter v1	1	2 (both working)	b
Linksys MR8300/EA8300, (EA7500)	1	2	a
Xiaomi AX3600	1	1+ 1not really usable	?
Xiaomi AX9000	1	2 (both working?)	b
GL.iNet GL-B2200	1	2 (both working?)	b
Linksys Velop (WHW01 v1 and WHW03 v2)	1	2 (different channel)	a
Meraki MR33	2	2	?

This PR should work for the usage of a and b by default, while the user can configure different behavior.

TODO:

• test on different three-radio routers
• disable option from gluon-web-wifi-config to configure a wifi on an unsupported channel if wireless.supports_channel(radio, config.channel()) is False

for two 2.4GHz radios, this does not disable one band by default, so it meshes on all by default - I think this is fine