My fault. defaultValue must pe placed outside of properties

@alexandrestein can I assume you‘re using NPTv6 on VyOS 1.2 series? If so you mind sharing an example/configuration so we can also improve our documentation?

@alexandrestein Sorry, I didn't understand some of them, but I opened this task list to track 1.3 nptv6 process, not about the DHCP support of wireguard. If you need this function or find that there is a bug in wireguard's DHCP, you should submit a bug report task list separately.

Thank you @jack9603301.

@Dmitry correct same bug - thank you. resolved.

@c-po I have never tested QoS on PPPoE in my lab. I'm having a look and come back to you.

I think this is a related task https://phabricator.vyos.net/T2591

https://github.com/vyos/vyos-1x/pull/457

Hey @zsdc , thanks for having a look into it.

Thanks to all of you

The patch was merged and the issue should be resolved with the next ISO.

https://github.com/vyos/vyos-1x/pull/456

@s.lorente can you check this with actually configured tc values?

This config was lost after first boot. Ping T2598
VyOS 1.2.3

And i wonder why there is a rule which is 'WANLOADBALANCE_OUT -p icmp -m icmp --icmp-type any -j ACCEPT'.
May i know the purpose of the rule ?

It seems to be ok in vyos-1.3-rolling-202006150117-amd64.iso. Thanks a lot.

When googling on the error given, T109 shows up where I had posted about this in 2018. I'm not sure it's related to this. Im not sure any configuration has been lost on reboot.

I did not config any nat rule.

Please also share your NAT configuration

And I found that when I changed the wan load-balance configuration, the load-balance process failed to come up.
And I excuted the show wan-load-balance command, it returned the message 'WAN load balancing is not configured'.
After reboot, it became all right then.

This is my config below:

load-balancing {
    wan {
        enable-local-traffic
        interface-health pppoe0 {
            failure-count 5
            nexthop dhcp
            success-count 1
            test 0 {
                resp-time 5
                target 119.29.29.29
                ttl-limit 1
                type ping
            }
        }
        interface-health pppoe1 {
            failure-count 5
            nexthop dhcp
            success-count 1
            test 0 {
                resp-time 5
                target 119.29.29.29
                ttl-limit 1
                type ping
            }
        }
        interface-health pppoe2 {
            failure-count 5
            nexthop dhcp
            success-count 1
            test 0 {
                resp-time 5
                target 119.29.29.29
                ttl-limit 1
                type ping
            }
        }
        interface-health pppoe3 {
            failure-count 5
            nexthop dhcp
            success-count 1
            test 0 {
                resp-time 5
                target 119.29.29.29
                ttl-limit 1
                type ping
            }
        }
        rule 1 {
            inbound-interface eth1
            interface pppoe0 {
                weight 1
            }
            interface pppoe1 {
                weight 1
            }
            interface pppoe2 {
                weight 1
            }
            interface pppoe3 {
                weight 1
            }
            protocol all
        }
        sticky-connections {
        }
    }
}

The same issue is present in site-to-site mode. local-host can be set there, but should not be required as the WAN ip might be dynamic

Probably is can be set in a curlrc file which is populated from CLI options

Confirmed fixed, thanks @c-po!

Add PR for CRUX.
https://github.com/vyos/vyos-build/pull/107
https://github.com/vyos/vyos-1x/pull/455

Booting on VMware ESX with EFI works as expected.

Is this still an issue? Or does it now work in EFI systems?

Okay, root cause is the extraction script which parses the Kernel source for included source/object files.

@jjakob by a weird coincidence I yesterday received a Thinkpad T420s which shows the exact same error.

You may use dpkg to unpack and install according to the following information:

This is the users dmesg with failed firmware load

[   21.951100] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[   21.951932] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-6.ucode failed with error -2
[   21.951961] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-5.ucode failed with error -2
[   21.951982] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-4.ucode failed with error -2
[   21.951985] iwlwifi 0000:03:00.0: no suitable firmware found!
[   21.958303] iwlwifi 0000:03:00.0: minimum version required: iwlwifi-6000-4
[   21.967817] iwlwifi 0000:03:00.0: maximum version supported: iwlwifi-6000-6
[   21.975992] iwlwifi 0000:03:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

In T2594#67314, @jack9603301 wrote:

For driver firmware, it's just a ko file, which can then be used by setting the boot in the configuration directory to automatically load the kernel file, or by using the following command:

depmod
modprobe myko

Considering the general Linux, the path of this driver and kernel component is usually:

/lib/modules/`uname -r`/kernel/driver/mymod/

Okay, the file is correctly installed, the question is, why the firmware is not accepted by the card. So there is no bug in general of the build system.

For driver firmware, it's just a ko file, which can then be used by setting the boot in the configuration directory to automatically load the kernel file, or by using the following command:

@jjakob installing all firmware files will again bload the image. As said - root cause must be determined why that particular file did not end up in the image. The repo holds the firmware in question (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/iwlwifi-3945-2.ucode) so I'm currently debugging why it's not shipped.

Adding custom install firmware command may be a good way. I tried to manually compile and upload firmware to vyos before.

I suggested to install the firmware-iwlwifi package from the debian repos as part of the debugging process. Of course this isn't a supported way for end users, this is known for a long time, and you must take care to not run apt-get upgrade, dist-upgrade or install a package that conflicts or overrides a vyos package. It is safe to install packages that don't conflict.

There are two main disadvantages to the third-party files and packages installed outside the packaged files of the installed vyos system. You need to determine by yourself that if:
a) does not match the basic debian system of vyos, ABI conflicts may occur.

Although this is not an orthodox solution, it is the fault of artificially installing drivers when there is a lack of drivers. Vyos is based on debian for secondary development, although unorthodox solutions should be allowed to use debian underlying commands to install appropriate firmware packages. Judging from the error message, it appears that the unpacking failed because there are other packages in conflict.

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

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: