Page MenuHomeVyOS Platform

Create op command to set regulatory domain
Closed, ResolvedPublicFEATURE REQUEST

Description

Users should have a command to easily set the country code (regulatory domain) for their wireless extensions.

Details

Difficulty level
Normal (likely a few hours)
Version
-
Why the issue appeared?
Will be filled on close

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:~$
alainlamar changed the task status from Open to In progress.Jan 23 2018, 10:17 PM
alainlamar changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).
alainlamar moved this task from Need Triage to In Progress on the VyOS 1.2 Crux board.

@c-po this thing should work already without T123, if someone can test this code on live hardware - it seems to be ready to merge.

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.

  1. 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.