luci-mod-network: add support for wireless no outdoor restriction

[Ansuel]

@jow- (sorry for the quote spam... I pushed v2 some times ago but got ignored so I wonder if an implementation in luci would move things up) This depends on the series [1]. The current implementation is a simple warning message on the wifi selection. This feature is useful for some Regulatory Domain like the Germany one where some channel are flagged as indoor only.

Some channels may restrict its use to indoor only. Add support for this and alert the user if a channel with this limitation is used.

Signed-off-by: Ansuel Smith [email protected]

[1] https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/

[jow-]

I think if we go that route we should handle all/most restrictions, also no-IR, no-IBSS etc.

[Ansuel]

Shouldn't be that hard. My only concern is about the ubus export... Should we export a string array instead of a Boolean for each restriction?

The rest of the implementation is the same.

Il Mar 22 Feb 2022, 22:37 Jo-Philipp Wich @.***> ha scritto:

I think if we go that route we should handle all/most restrictions, also no-IR, no-IBSS etc.

— Reply to this email directly, view it on GitHub https://github.com/openwrt/luci/pull/5695#issuecomment-1048236056, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2ZMQUPB6BUJQTO232XLQTU4P63PANCNFSM5PBPFITQ . You are receiving this because you authored the thread.Message ID: @.***>

[jow-]

I am undecided. In general I am also unsure if we should continue extending libiwinfo since changes like that usually break the ABI, resulting in various fallout and package upgrade coherency issues.

Since almost everything moves towards cfg80211/nl80211 these days it is maybe simpler to implement an rpcd exec plugin which dumps the regdomain, channel numbers/frequencies and restrictions instead of keep maintaining the additional libiwinfo abstraction which only made sense when non-mac80211 driver backends such as madwifi or wl were a thing. Can be initially scraping iw and later using a lower level binding. I know that this is a bit outside of the scope of this initial implementation proposal but it'll allow for better wireless configuration capabilities in the long run

[Ansuel]

So you are suggesting a module that bypass iwinfo. AFAIK scraping iw is not advised as the output can change. Will check how overkill is to do what you are suggesting. If you have other suggestions about the implementation fell free to write them.

Il Mar 22 Feb 2022, 23:24 Jo-Philipp Wich @.***> ha scritto:

I am undecided. In general I am also unsure if we should continue extending libiwinfo since changes like that usually break the ABI, resulting in various fallout and package upgrade coherency issues.

Since almost everything moves towards cfg80211/nl80211 these days it is maybe simpler to implement an rpcd exec plugin which dumps the regdomain, channel numbers/frequencies and restrictions. Can be initially scraping iw and later using a lower level binding. I know that this is a bit outside of the scope of this initial implementation proposal but it'll allow for better wireless configuration capabilities in the long run

— Reply to this email directly, view it on GitHub https://github.com/openwrt/luci/pull/5695#issuecomment-1048270028, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2ZMQVI2AQZUXTYAWH65KTU4QEJJANCNFSM5PBPFITQ . You are receiving this because you authored the thread.Message ID: @.***>

[Ansuel]

@jow- Ok i have implemented a module to rpcd that implement direct access to nl80211

this is the current output

What do you think? Want me to publish the source code? I assume it would be stupid to push an RFC with a WIP so pls tell me how we can track this so you can add comments or NACK...

[Ansuel]

@jow- here the gist with the patch and the makefile https://gist.github.com/Ansuel/c6ff30bb84fa4b74cf15868abb7db929

[Ansuel]

@jow- any news on this? what do you think of the nl80211 rpcd module?

[Ansuel]

@jow- friendly remainder if you have news about nl80211 rpcd module

[Ansuel]

@jow- I updated this... The outdoor channel patch got changed to provide also the no_ir value for consistency...

Since everything is added to the flags we can add additional flags in the future without changing the ABI... we should have plenty of space since it's a 32bit value.

This strange if condition is there as ideally this will be expanded for the no_ibss once we sort everything for the ABI change.

				if (data[1][i].restricted)
					if (data[1][i].no_ir)
						available = false;

Aside from that this required tons of changes since we were currently based everything on a bool value to flag band frequency or mode as disabled but that is problematic for this task... So i converted that value to a dictionary and the old bool is now the available flag.

We still need to decide about the yellow warning box... Any hint about that?

[dhewg]

I am undecided. In general I am also unsure if we should continue extending libiwinfo since changes like that usually break the ABI, resulting in various fallout and package upgrade coherency issues.

Since almost everything moves towards cfg80211/nl80211 these days it is maybe simpler to implement an rpcd exec plugin which dumps the regdomain, channel numbers/frequencies and restrictions instead of keep maintaining the additional libiwinfo abstraction which only made sense when non-mac80211 driver backends such as madwifi or wl were a thing. Can be initially scraping iw and later using a lower level binding. I know that this is a bit outside of the scope of this initial implementation proposal but it'll allow for better wireless configuration capabilities in the long run

@jow- Somewhere else you also mentioned the idea of replacing libiwinfo with an ucode implementation. Since you already wrote ucode-mod-nl80211 that'll even be rather easy. To some extend at least, because it does a lot more than abstracting nl80011, like reading hostapd conf or talking to wpa_supplicant or accepting uci radio names.

Now that I messed with pretty much all corners of libiwinfo, and considering what other packages gain and actually do from/with such a library, I believe it makes sense to keep a C API for this. And then we could just incrementally clean it up and fix stuff - it's salvageable ;)

As I'd like to use iwinfo features from ucode, do you have plans on how to proceed? Or some sort of TODO list for where it sucks and what needs to be improved?

[systemcrash]

@Ansuel can this go in as is? I dig the rpcd thing.

[Ansuel]

@systemcrash I have to rebase this... anyway main problem of this was deciding what was the best way to display that an outdoor channel was used... @jow- has some concern and didn't like the design of it.

[systemcrash]

Advice is the noun.

Advise is the verb.

Use advice.

[knarrff]

Advice is the noun. Advise is the verb. Use advice.

I followed your advice and changed my comment. :-) Thanks

[systemcrash]

@Ansuel please rebase. Then we can merge. Any cosmetic tweaks can go in later.