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

Sorry, I have changed the repair implementation
PR: https://github.com/vyos/vyos-1x/pull/638

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.

Unfortunately this is the wrong way to go. If it is - for whatever reason - not possible to configure the VLAN parameters for this given interface b/c the enslaved interface is yet not present on the system, it should be later configured by the individual interface.

Tried this patch with @jack9603301 , it solves the problem for me.

@c-po Please merge this PR, the problem will be fixed directly

I may have to change the configuration priority. Due to priority issues, the settings may fail

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

@primoz Can you contact me in Slack?

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

Thanks for the quick fix!

@primoz Delete the old one, create a new bridge after commit, and then commit. Can it work normally?

it's an edit + delete/delete/delete ... no creation (at least in my edge case).

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'

@c-po Does the deletion of the bridge occur after the new bridge is created or before?

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.

As it looks to me (but i'm not sure yet), the configuration system is fixing devices one by one and was trying to add port into new bridge before the old bridges were removed (and so ports were still in them). If this is the case ... not sure that there even exist an easy fix.