Users should have a command to easily set the country code (regulatory domain) for their wireless extensions.
Description
Details
- Version
- -
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | FEATURE REQUEST | alainlamar | T452 WiFi: Enable support for 5GHz AccesPoints with DFS | ||
Resolved | FEATURE REQUEST | alainlamar | T529 Create op command to set regulatory domain |
Event Timeline
Pull request created: https://github.com/vyos/vyatta-wireless/pull/9/files
This pull request implements the operations command: set wifi-regdom <country code> which will change the country code in files /etc/default/crda and /etc/modprobe.d/cfg80211.conf. If any of those files is non-existent, it will be created.
vyos@ap-test:~$ set Possible completions: <OPTION> Bash builtin set command console Control console behaviors date Set date and time system Set system operational parameters terminal Control terminal behaviors wifi-regdom Set WiFi regulatory domain (country code). Afterwards, you must restart VyOS for the settings to take effect. vyos@ap-test:~$ set wifi-regdom Possible completions: <text> Set regulatory domain (country code) globally for all WiFi interfaces. YOU MUST RESTART VyOS FOR THE SETTINGS TO TAKE EFFECT! vyos@ap-test:~$ set wifi-regdom DE Possible completions: <text> Set regulatory domain (country code) globally for all WiFi interfaces. YOU MUST RESTART VyOS FOR THE SETTINGS TO TAKE EFFECT! vyos@ap-test:~$ set wifi-regdom DE vyos@ap-test:~$
Hi folks,
thanks for your support!
I had a chat with @syncer yesterday, where we also discussed the approach of setting WiFi regulatory domains. We agreed upon two issues prompting for an Architect's decision (@dmbaturin):
- Code that does persistent changes should go to the configure section. This would mean three things:
- The part writing to files would be moved to T452.
- Backward compatibility in T452 would be broken as the set interfaces wireless wlanX country DE node would be moved in front of the interface name tag config node: set interfaces wireless regulatory-domain DE which would allow for a complete and easy to understand way of making all persistent changes in one go.
- The call to the iw command may remain here and this command would be reduced to a wrapper for calling iw reg set DE; iw reg get.
- No excess root nodes should be added to the syntax tree. The syntax proposed in this pull request would add the wifi-regdom node which is not re-usable. We have yet to agree upon a new operational node name which is more useful for other tasks as well or another place where to put this function. Proposual (op node): set wireless regulatory-domain DE
So, please don't merge yet, I'll wait for the decision and then implement stuff accordingly.
Thank you! :-)
Al
@mickvav sure it will work without T123 and a test is very good.
But, we should also try to find a generic approach to configure Kernel modules if possible. If there is no super generic way or we would have to do a lot of chin-ups, I‘m in with every other solution.
Again @alainlamar thx!
@c-po I don's think that there is unique-one-ideal way to configure kernel modules in run time - some of them have interfaces as files in /proc or /sys filesystems, some don't and expect some ioctl on some /dev/ device or on some network device. Others, as netfilter, expect whole bunch of binary data to be pushed to kernel after being compiled by their own userspace tool.
As far as I understand, what we can do - is to make some use of sysctl to adjust the parameters that it can access. Thus, more or less generic way is to call sysctl something=somevalue in op mode and to write something=somevalue to file like /etc/sysctl.d/path_to_conf_entry.conf together with calling sysctl something=somevalue in configuration mode. This way we can get more-or-less generic way to describe sysctl's parameters in conf and op mode.
Please keep in mind:
- ioctl() like interfaces are usually proprietary or encapsulated by the socket API (keeping the fucus on a network device only here)
- systl is used for tuning kernel internal parameters that are usually compiled statically, most of the time it wraps the /proc pseudo filesystem, e.g. networking stuff
- /etc/modprobe.d is used by modprobe for kernel load parameters when the module is inserted. Sometimes they can be manipulated by sysctl, sometimes not. Always depends if the module has been loaded before calling sysctl or where in the driver this setting is referenced.
The challenge is to find an abstraction/automatism to use the appropriate interface for a common VyOS configure node... Thats whats T123 should be about.
As pointed out in T529#11515, I rewrote this command to now do the following:
set system wifi-regulatory-domain DE
This will call iw reg set DE and try to set the regulatory domain to DE. No persistent changes are involved. The Kernel may silently refuse to change the regulatory domain under certain conditions, so I added a call to iw reg get to print the current settings for verification.
show system wifi-regulatory-domain
This will just call iw reg get and print the current settings.
The persistent changes have been relocated to T452 (see R37:95bd203371e51ca42a7b2b39b4893dd1b8014d34) as config mode setting:
set system wifi-regulatory-domain DE
No Kernel parameter setting is involved here. The iw command seems to reach directly into the Kernel.
Please test and consider for merge.
- A nicer version of os.system('iw reg get')
This makes me think we should make a shared nicer version that returns a tuple of exit code and combined stdout/stderr and put it somewhere in a utility module.