Add PR for rolling https://github.com/vyos/vyos-1x/pull/462

There is another use of is_tag/is_leaf in python/vyos/validate.py is_member, as it can work on both bridge and bond members, and they have different syntax for member interfaces. It would only be possible to hardcode each case and remove the use of is_*

In the latest rolling, I don't see this bug.

VyOS 1.3-rolling-202006170117

Hmmm is it the fact I have a remote syslog configured that triggers this bug?
I didn't realise that, I'll have to remove it and see if it helps.
It's very frustrating not having the firewall logs available to view.

For what little to no weight my opinion matters, I also agree that this should be backported to Crux.
As I've bashed my head into it testing :-)

Implementation steps:

1. Add $INCLUDE dictionary.rfc4849 to /usr/share/accel-ppp/radius/dictionary file
2. Add required modules for use ip-pre-up/ip-up/ip-down scripts

[modules]
sigchld
pppd_compat

And pppd_compat params

[pppd-compat]
verbose=1
ip-pre-up=/path/to/ip-pre-up 
radattr-prefix=/var/run/radattr

3. Create ip-pre-up/ip-down script which will get configured firewall names and rules from CLI or supported script

Note: When ip-pre-up return 1 then the session will not start like described in https://tools.ietf.org/html/rfc4849

Fixed https://github.com/vyos/vyos-1x/pull/460.

Does not possible to disable ccp in l2tp

vyos@RTR1# set vpn l2tp remote-access ccp-disable 
[edit]
vyos@RTR1# commit
[ vpn l2tp ]
VyOS had an issue completing a command.

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

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.

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

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

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

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.

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.