Any rolling ISO generated after vyos-1.3-rolling-202006140117-amd64.iso will have the fix.

It now renders to:

The mentioned configuration results into this snippet on VyOS 1.2.5

It is not recommended to install Debian firmware- packages over vyos-linux-firmware. The question is why the firmware file in question is not pulled in automatically.

T2569 did an entire rewrite of the console command in XML / Pyhton. Bugfix for this problem is also tracked in that task.

Non-free firmware was added by default in crux: T15

There's a regression here, I can not 'delete system console' in the current rolling build, I get this:

@daniil it will be fixed in tomorrows rolling ISO.

Just adding that I too am experiencing this same issue with 1.2.5 while sending firewall logs to a remote syslog server. Running the command

sudo systemctl restart rsyslog

will show firewall logging for a few seconds before it stops completely. Issuing the command again will result in the same thing - logs for a few seconds and then stop. It appears that logging outside of the firewall still functions as expected as regular console log entries are still being sent.

Can you share what you did to make it work again? NAT has recently be rewritten which could be the root cause.

A config Syntax is always migratable. Wide also supports scripts, but ISC PD (as I‘ve seen it, and interpret it) seems to have some rough edges. If you find a guide I will definately have a look.

I have no need for PD for now, so this isn't an important issue for me. I just noticed that WIDE didn't run any scripts, so right now it can't set any nameservers obtained from DHCP. If anyone needs that, I guess it would be simplest to write a script (by using the existing dhclient-script hooks as a guide) just for vyos-hostsd, since PD is already done with WIDE. Switching to ISC would mean we'd need to improve that PD script I linked to, since it only supports a single interface, and we need multiple.

@jjakob it was only choosen as it prooved to be "more simple" compared to ISC and that helper script. I have no affiliation with either implementation. I was not aware that it could cause other issue. If you need to change it to ISC you're free to go.

@jack9603301 you're not the one that made the choice so you can't know why it was made.
ISC-DHCP can do prefix delegation too (not by itself, but with a helper script that others already made: https://wiki.debian.org/IPv6PrefixDelegation ) so that's not why WIDE was chosen.

The purpose of choosing wide-dhcpv6 is to achieve DHCPv6 PD.

What was the reason for choosing WIDE dhcp6c and not keeping isc-dhcp? This has now caused T2590 which will require making a new set of dhclient scripts just for WIDE, so we'll be maintaining 2 separate scripts. If it was due to the support for prefix length hint, isc-dhcp has added that too, as I mentioned in this task before https://phabricator.vyos.net/T421#49842

Successfully tested on 1.3-rolling-202006120643

Successfully tested on rolling 1.3-rolling-202006120643

Unfortunately this results in an error:

As a side-note, the kernel reacts correctly to this by rfc6145.

An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes.

Hmm, sshd listens on port 2 by default.

SNMPD must listen to the socket on the loop in vrf default. This is necessary for the protocol agentx to work.

The set protocols bgp XXX neighbor XXX address-family ipv6-unicast peer-group XXX command generate the router bgp XXX; address-family ipv6; neighbor XXX peer-group XXX', for vtysh, which does not supported (anymore? I cannot find any commits in FRR about syntax change, maybe this was migrated from old quagga).

This fixed now introduced a bug with comma separated ports

Please feedback as this is what you expect. Also it would be nice if could write something about that in our documentation: https://docs.vyos.io/en/latest/

Latest rolling release has all the fixes

Works as expected

The != port issue is yet to be fixed ...

Tomorrows rolling ISO will support VRF sourced SSH.

1. commit restrictions/permissions have not changed; all handled in the backend.
2. The daemon can not load the configs, as it does not have/need access to the config session; that's the point.
3. ?
4. the conf_mode script needs to reference the global config; re-setting level is basic hygiene --- the script should ask itself 'what if I am called again?'
5. we want to eat the args in the node.def; so you already have it.

Thank you very much for the POC. Very useful to understand the proposed design.

While I agree, that caching is a feature of the past, we rely heavily on vyatta-webproxy for authentication and also url-filtering (different source networks allowing access to different destination domains and/or IP ranges).

Here is my config commands that are having the "!" issue on the adddress, 3 separate NAT rules where I am using NAT to catch sneaky DNS bypass and redirect through my infrastructure

Just adding in here that it is also affecting ip addresses too, not just ports
I am on 1.3-rolling-202006101523

+1 for this, it would be very useful for a lot of use cases, we wouldn't need to add everything to vyos-1x and the config syntax, but users could add "missing" services on their own. For example T2195