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.

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

Do you have any good fixes?

first delete original, commit, then new and final commit.

You mean, if you submit it in 2 steps and configure it separately, it works fine?

For some reason ... nothing in logs:

It works nicely with VXLANs ... no problems there. You can use it like this to get local port into vxlan (without this, vxlans become useless). I have problems with bond interface (everything else works). Debugging now.

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

Can I restart ping? Can be restored after restart

Running VyOS 1.3-rolling-202012060217 immediately when I enable port mirroring all sessions are dropped on this link.

Please only allow native-vlan and allowed-vlan for ethernet and bond type of interfaces for the time beeing

Please only allow native-vlan and allowed-vlan for ethernet and bond type of interfaces for the time beeing

Logically speaking, any interface that can be added as a member interface when setting the bridge interface should be fine. bridge vlan applies to any member interface, but I don’t know why it is sometimes possible and sometimes not. I need More information to determine the problem (since there is a situation that can be set successfully, and no abnormality is reported, then the setting should be successful, WLAN is not working because the WLAN bridge is set by hostapd)

I wonder if this configuration should be possible at all. In my opinion native-vlan and allowed-vlan should be supported only on bond and ethernet interface types

Taking the following configuration as a pool serving relays:

Put in a new PR to enable LDP local label allocation control.

I don't know what you mean?

Disable downgrades in general is a bad idea. We still can leave the user with a broken config on downgrade but prevent it is bad. Imagine a very simple config, that would be downgradable.

successfully tested on the self-build image from crux branch and the latest rolling image

Before that, should we consider completely migrating the vyos firewall implementation?

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

yes, specifying "ipv6" has the same effect as "ipv6 enable"

Do I only need to execute the following commands when I want to start ipv6?