I got this when several times change boot with

set system image default-boot

1.2.6 => 1.3 => 1.2.6 => 1.3

I successfully update the image from 1.2.6-s1 to VyOS 1.3-rolling-202012231522

Thanks for the feedback and telling us about how to solve this issue.

Successfully tested on 1.3-rolling-202012230217

The main problem is that you use the same name for different group types.

@tjh How you want to integrate it with CLI or use it as a separate pkg?

The issue turned out to be at the host level. By default SR-IOV VFs are not allowed to change their own mac addresses or send packets with a different mac address, and since this is required for LACP bonding the configuration would just fail.

@robertoberto Can you provide next commands?

show interfaces ethernet eth0 physical
sudo ethtool -k eth0 | grep offload

Put in a PR to add LDP ordered control operation for LDP.

@primoz What are the benefits?

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

https://github.com/vyos/vyatta-cfg-system/pull/134

This breaks with common configuration patterns/naming in Wireguard. Nobody will know what you're talking about when you say address and port in this context. And the CLI helpers adds documentation that would lead you to believe you are listening for connections, see line 105 in nterface-definitions/interfaces-wireguard.xml.in.

dhcpcd is a pretty good alternative. Well maintained and popularly used by many. I used it in a plain Linux router project and it was good enough for my use cases.

PR for crux https://github.com/vyos/vyos-build/pull/138

It still would be nice though. ANy other good IPv6 DHCP clients out there?

Yeah also it looks like wide is hardcoded to support only type 1 DUID (LLT) anyway.... so probably it wasn't accidentally "forgotten" in 1.3 migration that someone probably has realized it wasn't viable to support it... Thanks :)

Undortunately it only worked in 50% of the cases properly. Also there is only one global duid file so you can not have multiple duids (one per each interface).

@vagardx thank you for this rant.

Sorry I am confused. I took a brief look at the code of dhcp6c and it appears manually modifying the dhcp6c_duid file should be able to keep the change persistent: https://github.com/jinmei/wide-dhcpv6/blob/24ee2a4f0009bc6ac9bd0b7b737aef93a4aa9905/common.c#L992. Did I miss anything? Thanks :)

Accidentally deleted the comment. Is there plan to migrated to dhcpcd instead? dhcpcd has good ipv6 support and being actively maintained too. Thanks.

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

This breaks with standard configuration convention in Wireguard. Also, no documentation has been updated to reflect this breaking change.

I want to know the behavior of the implementation when upgrading the vyos version

It looks like wide dhcp client does not support setting the DUID as it is overwritten again after a restart :(

PR https://github.com/vyos/vyos-build/pull/137
PR https://github.com/vyos/vyos-1x/pull/651

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

Put in a PR to add op commands for LDP.

PR:

So how are userspace packages for this sort of stuff handled? I assume we need to itemize out individual phabricator tickets?
Off the top of my head, relevant things to add to uspace would be:

1. eoip binary
2. eoip CLI wrapper
3. Xtables userspace with GeoIP table data and updater script (we would need to figure out how to deal with rule placement for persistence)
4. Xtables-related CLI for firewall matching on GeoIP, DNS, etc
5. Xtables-related CLI for firewall actions to TARPIT or DELUDE
6. UKSM userspace (or just wrappers for the sysfs interface in CLI)
7. Hardened Malloc with system-wide LD_PRELOAD or maintain a vyos-specific libc package with it built-in

The CLI command set interfaces ethernet <interface> offload-options xdp enables the XDP generic mode on the given interface.

Ok. I will try to use containers, this good idea.
Containers will be more predictable and stable I suppose.

@vlesk once container support is added you have a better way by usibg a dedicates container on your VyOS installation.

If your device supports virtualization, you can consider running both VyOS and cups servers in KVM (there are many open source projects that can do this, such as Proxmox Ve)

Yes I know that I must install printer driver. I successfully solved this problem long time ago by using additional partition. And YES I KNOW that VyOS is not a general server operating system. But some time convenient use ONE universal host instead two or more.

Why install the remote print sharing service on the router and use cups, you must install the printer driver on the cups server to make it work. VyOS is not a general server operating system, so you should install cups on a physical server or virtual server

I prefer build images with some additional packages, such as cups. For example in order to administer printer I should add user to group lpadmin. In releases 1.2.x it was easy, but now I necessary after each update do it manually.