Why you would line to add a user to an additional group?

Where possible, we can consider MBR+UEFI dual boot, which also exists in most distributions

Furthermore, I've attempted changing the interfaces-wireless.xml.in priority to a value before interfaces-bridge.xml.in and it still fails. Not sure how else I can debug.

I just tested 1.3-rolling-202012141037. It actually seems to be a bug. When applying wifi settings and adding to a bridge in the same commit, I'm hit with

In T1773#46307, @runar wrote:

With this, will there also be possible to parse the same json into an json import? This to allow for a more programatic way to add things than via set commands

PR: https://github.com/vyos/vyos-1x/pull/644

@owensresearch it is still not supported by net-snmp

Put in a PR to fix spelling/help string error. My bad. I didn't catch it before.

Did anything ever come of this? I have a handful of IPv6 BGP sessions as well as LibreNMS to test...

Please note that the card must be configured to be in AP mode first. The link @c-po mentions highlights that you can't add a wireless interface to a bridge if it is in client mode.

It was deleted/deprecated in T1990

I checked.
In version 1.3-rolling-202012110217 issue fixed.

Using udp4/6 can be automated if there is an v6 listen address or not, I will keep this in mind, thanks for the hint.

@vlesk Will be fixed in the next rolling release.
Can you check the release after 10 Dec?

PR https://github.com/vyos/vyos-1x/pull/641

I mainly have 2 questions:

To reproduce

set interfaces vti vti2 address '10.0.0.1/30'
set interfaces vti vti2 description 'Tunnel to 100.64.0.2'

Put in a PR to add documentation for LDP import/export control again. I didn't rebase properly last time. Sorry everyone :(

Maybe this implementation also has a dependency problem, I will fix it in the near future

Put in a PR to add LDP import/export control.

In T3117#81576, @c-po wrote:

Unfortunately setting udp4 was never "valid" in the first place, this was only possible by a wrong regex here: https://github.com/vyos/vyos-1x/blob/406083932ae62ccde5ff547ef7d7960efe0269e3/interface-definitions/interfaces-openvpn.xml.in#L345 this has been corrected already which shows the above mentioned result in a not loading config.

Unfortunately setting udp4 was never "valid" in the first place, this was only possible by a wrong regex here: https://github.com/vyos/vyos-1x/blob/406083932ae62ccde5ff547ef7d7960efe0269e3/interface-definitions/interfaces-openvpn.xml.in#L345 this has been corrected already which shows the above mentioned result in a not loading config.

PR for fixing bgp template (prefix-list) and add the ability to use updated frr.py framework functions.

how to build any version of linux kernel using build-kernel.sh and make iso?

some corruption. I redeployed the instance and copied the config over and now it works.

To clarify, in this case I am trying to commit a config with an interface that's configured as an AP.

Well this is from old Vyatta times, on system bootup this script is called (https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/system/vyatta_interface_rescan#L137-L140) and a WIFI node is created if a wifi interface is detected. The script could be altered, too if monitor is not supported.

@bbs2web, here's what I got...

@bbs2web, getting this one (https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202012070521-amd64.iso) and will troubleshoot...

That's a little unclear to me. If the interface is defined but doesn't yet exist, then it needs to be created. A brief look at the code makes it seem like it always creates new interfaces with type=monitor.

I guess the best thing would be to not add this interface at all

Important note on this PR - in order to build the GCC plugins which perform most of the self-protection work, the Docker container needs gcc-8-plugin-dev installed. Otherwise it builds, but silently downgrades the configs dropping RANDSTRUCT/STACKLEAK silently.
Pulled RSBAC out for now (issues with building the rest while its in there but disabled), validated builds with and without the plugins package for GCC8.

Installed 1.3-rolling-202012060217 yesterday and the VLAN interfaces don't appear to get MPLS enabled. I essentially removed the following lines, which work as expected when present:

set system sysctl custom net.mpls.conf.eth0/11.input value '1'
set system sysctl custom net.mpls.conf.eth0/13.input value '1'
set system sysctl custom net.mpls.conf.eth0/14.input value '1'

Added an inert patch (disabled in Kconfig) for https://www.rsbac.org/ on 5.4. This can be used to significantly harden the restrictions intended by the CLI to limit users to specifically defined roles, same goes for applications/containers.
If adding container support to VyOS is still on the roadmap, we're going to want to take extra care to enforce the boundaries between them and the host since real world use cases are pretty much guaranteed to leave old vulnerable containers running on long-running network appliances making for a variable and worsening attack surface over time.
This isn't quite as integrated and doesnt provide nearly the coverage as what you get with grsec+pax, but a rough approximation of "role-based FS restrictions and runtime hardening" is now in the pull request along with the other stuff which seemed pertinent for upstream.

Thank you sir. Worked through a clean build, updated patches, rebased, and pushed.

OK, the latest PR can be tested. I just tested the basic functions and the effectiveness of the migration script. But I haven't submitted the PR of vyatta-cfg-system

Okay, debugging with @jack9603301 showed that there was/is an issue. If you are running DHCP client on the interface which is using mirroring, this indeed becomes an issue as traffic is dropped until the session is re-established.

In the latest PR implementation, eth0 will shake at the moment when the eth0 configuration is changed, but it seems to be restored immediately

In the test topology, the same situation was found in the mirror test of pppoe0

I am a little doubtful whether this is in design, and whether there will be a short-term up to down to up conversion when the interface is modified.

Of course, restarting ping works, but all flows in transit will stop, this is not what you wan't on an edge device running 10GBit/s of traffic