Likely be addressed in 1.3

We may want to consider other backend for web proxy functionality

Deprecate that function, and push resources to building on Core routing and Code stability

the file used for the package "version" is the changelog file.

I seem to be wrong with my initial statement where to set the version. The file debian/vyatta-wireless/DEBIAN/control is not even in version control and I can't seem to find a hint on where this version string 0.3.41+vyos2+current1 really comes from.

@dmbaturin @UnicronNL can you comment on this

@alainlamar clearfog is the ARM build for https://www.solid-run.com/marvell-armada-family/clearfog/

Cheers @c-po! Unfortunately, the build failed with reference to "clearfog". Do you know what this is or if I could fix this somehow in vyatta-wireless?
Right now, I have no idea...

... done

In T452#11673, @dmbaturin wrote:

Merged.

It will have to be refactored for the new vyos-1x approach, but then the entire package will, so we'll better have the .ac support now, and refactor later.

for type1 we need setup LACP by default

It will have to be refactored for the new vyos-1x approach, but then the entire package will, so we'll better have the .ac support now, and refactor later.

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.

As pointed out in T529#11515, I rewrote this command to now do the following:

I'd like to prompt for a decision:

• break backward compatibility to implement the above scheme (I'd suggest that) or
• stick with this pull request (T452) and work around the regdom-setting by using the existing pull request in T529.

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.

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

@mickvav sure it will work without T123 and a test is very good.

In T529#11515, @alainlamar wrote:

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 from T529 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. [...]

Hi folks,

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

@alainlamar , well done!

Looks like one has to run also something like

Related to T123

Pull request created: https://github.com/vyos/vyatta-wireless/pull/9/files

Pull request sent. Please consider a merge.

That is fine, maybe with exception for some nasty vulnerabilities, however we also not disappear
just handy to have someone dedicated to wireless (almost separate world)
Thank you!

@syncer thanks for the offer :)

@alainlamar by any chance you want to be maintainer of wireless subsystem ? :)
It looks like you both have knowledge and real life use case and that make it whole easier

@alainlamar nice work digging!

I found an example file in vyatta-lldp:

I found an example XML tag config file in vyatta-lldp:

@dmbaturin Yes, as time permits. That's my worst constraint.

Hey everyone,

@c-po I did some major work on vyatta-wireless, including the introduction of nested nodes to configure card capabilities. Would you mind to take a look at it and suggest improvements for:

• using a better way than Perl smartmatch to compare strings against arbitrary lists of strings (like in Python if "bar" in ["foo", "bar", "baz"]: print("True"))
• a nicer way to getting rid of mutual exclusions without adding too much responsibility on parsing by wireless-hostapd.pl. Transforming ht and vht from multi nodes into nested directories and then implement a bool node for each capability flag would IMHO require much more parsing in wireless-hostapd.pl but would solve the issue with mutual exclusions which could be implemented as simple multi-choice nodes...

In T452#10768, @c-po wrote:

@alainlamar Kernel Updated and Rebuild triggered on CI server.

@alainlamar Kernel Updated and Rebuild triggered on CI server.

Today, I had a look into the vyatta-wireless package to see if I could hack something up to work with the new Kernel changes via VyOS CLI.

Pushed here for review: https://github.com/c-po/vyos-kernel/commit/0456e0acdcc5b9545723f57ebf489f2a1801a864

@c-po here you go:

@alainlamar thanks for your effort! Could you please regenerate your patch against arch/x86/configs/x86_64_vyos_defconfig which is used for the CI builds?