Complete rework of internal OpenWrt wifi config handling

Hi,

having cleaned up a lot of different areas of OpenWrt over time, one remaining area that needs some work is the handling of wifi interfaces.
One major limitation in the current design is that whenever the configuration of a wifi device changes, all interfaces need to be brought down and up again, causing connectivity loss for unrelated interfaces.
There has been an attempt of fixing this in the existing mac80211.sh shell code, but it was overly complex, and the internal hostapd reload code it was relying on is fragile at best.
In general, the current mac80211.sh + hostapd.sh code is rather convoluted and badly in need of a rewrite.
That said, a few of us started working on cleaning up and rewriting the messy bits.

As a first step, I changed the hostapd package to create a ucode instance inside the hostapd/wpa_supplicant processes for dealing with dynamic reload.
I kept mac80211.sh mostly structurally unmodified in order to reduce the potential for regressions. I moved all code for creating interfaces and tracking their state to the ucode scripts run by hostapd/wpa_supplicant.

In its current state, my rework handles dynamic reload rather well. It can handle adding, removing or changing individual AP interfaces without affecting the others.

You can find it in my staging tree at https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary

In the mean time, John is working on rewriting mac80211.sh + hostapd.sh in ucode, which will make it a lot simpler and easier to extend.
Given that his rework will be a lot more intrusive than mine, we need to make sure that testing of our changes starts early, in order to avoid introducing big regressions.

If you have any complex wifi setups (e.g. many different interface types), or if you do frequent configuration changes, it would be good if you could test my staging tree to make sure it works well in your tests.

Please let me know if anything breaks.

Thanks,
Felix

13 Likes

does running two ssid on single 2.4Ghz counts ?

Felix, maybe it's a bridge too far for now, but any chance this would result in a seamless/uninterrupted mesh when the radio channel is changed on the gate connected node and other nodes need to follow?

What are the timeframes to have your changes merged to main branch and (the next I presume?) release?

Tagging @bluewavenet as we've had a similar discussion in the past.

I'm planning on merging this to master maybe in a few days or so, if I get good test feedback and no serious regressions show up.
It doesn't implement graceful channel change handling for mesh yet, but it definitely makes it easier to add in the code.

1 Like

The 802.11s standard has no means for propagating a channel change out from a mesh portal to all the peer nodes in the mesh, so no, nothing here will give the result you are looking for.
There are/have been proprietary solutions to this, but they are very hardware specific in most cases, or use a layer 3 wrapper to provide some necessary communications.

FYI In the terminology of the 802.11s standard:

  1. A mesh gate has a downstream connection to another network, for example an access point (AP), or an ethernet link to numerous APs. So an AP that also has a mesh interface will be a "mesh gate"

  2. A mesh portal has an upstream connection to other networks, usually the Internet. So a router connected to an Internet feed and having a mesh interface will be a "mesh portal".

@nbd
I'm happy to do some testing, particularly with my interest in mesh ie to make sure nothing gets broken with respect to mesh :wink:
Unfortunately I do not currently have the facility to build from your staging tree and don't have the time to set anything up.
Are we taking about just the netifd and hostapd packages?
If you are able to build me ramips packages I could do some testing immediately.

1 Like

Something I've observed on my mt7622 target device was with just simple configuration changes it works perfect but after a full device reset the default wireless operating freq (mode, channel, width) was set to legacy mode for the 2.4GHz radio and not set at all on the 5GHz radio.

@Gingernut does the same happen for you in a recent snapshot without my changes? can you please tell me which device you are using and send me your .config?

Just retested and it seems to be a luci visual problem as /etc/config/wireless is correctly populated.

Sorry for the noise and thx for your work.