In the specified timerange

Next rolling release will carry the revert

Thank you for the feedback! Will incorporate this into the rolling releases. Looks like once again Intel did us a favor.

Your revert appears to do the trick. Image booted fine with QAT enabled, and "show system acceleration qat status" shows the QAT device came up fine and is running happily.

@c-po It was thought that possibly the nftables migration was doing something funny here because of the potential overlaps.

I will take at look if I can implement a short fix to generate IPv6 Link Local addresses on wireguard interfaces.

Further configurations and an overview via email

@cjeanneret Can you re-check it? And close it if all works fine.

T3060

Fix for "remote-host" on client side
PR https://github.com/vyos/vyos-1x/pull/606

Server conf

set interfaces openvpn vtun0 encryption cipher 'aes256gcm'
set interfaces openvpn vtun0 encryption disable-ncp
set interfaces openvpn vtun0 hash 'sha512'
set interfaces openvpn vtun0 local-host '100.64.0.1'
set interfaces openvpn vtun0 local-port '1194'
set interfaces openvpn vtun0 mode 'server'
set interfaces openvpn vtun0 openvpn-option 'tls-version-min 1.3'
set interfaces openvpn vtun0 openvpn-option 'comp-lzo no'
set interfaces openvpn vtun0 persistent-tunnel
set interfaces openvpn vtun0 protocol 'tcp-passive'
set interfaces openvpn vtun0 server client client1 ip '10.10.3.2'
set interfaces openvpn vtun0 server client client1 subnet '10.10.3.0/29'
set interfaces openvpn vtun0 server client client1 subnet '10.20.0.0/16'
set interfaces openvpn vtun0 server subnet '10.10.3.0/29'
set interfaces openvpn vtun0 server topology 'subnet'
set interfaces openvpn vtun0 tls ca-cert-file '/config/auth/ovpn/ca.crt'
set interfaces openvpn vtun0 tls cert-file '/config/auth/ovpn/central.crt'
set interfaces openvpn vtun0 tls dh-file '/config/auth/ovpn/dh.pem'
set interfaces openvpn vtun0 tls key-file '/config/auth/ovpn/central.key'

The check on DH length is backwards.

I have reverted the commit of QAT driver update. can you please try out this image:

In the new version client configuration

Request merge PR:

Usually all of them have a serial failback thus they should work, currently there is only a smakk subset of vyos verified LTE modules as each and every modules comes with its own problems:

How about these changes https://github.com/vyos/vyos-1x/blob/current/src/op_mode/powerctrl.py#L37

diff --git a/src/op_mode/powerctrl.py b/src/op_mode/powerctrl.py
index 69af427e..c000d7d0 100755
--- a/src/op_mode/powerctrl.py
+++ b/src/op_mode/powerctrl.py
@@ -34,7 +34,11 @@ def utc2local(datetime):
 def parse_time(s):
     try:
         if re.match(r'^\d{1,2}$', s):
-            return datetime.strptime(s, "%M").time()
+            if (int(s) > 59):
+                s = str(int(s)//60) + ":" + str(int(s)%60)
+                return datetime.strptime(s, "%H:%M").time()
+            else:
+                return datetime.strptime(s, "%M").time()
         else:
             return datetime.strptime(s, "%H:%M").time()
     except ValueError:

@Zer0t3ch Can you share your configuration?

There are also other huawei LTE WWAN USB modules which use CDC/NCM drivers.. such as E3276 and E3372.. so it's not possible to use these anymore? I actually haven't used those with vyos myself yet, but I was planning to try it soon, as I have those USB WWAN modules available, and I've been using them with other linux distros (with cdc/ncm drivers).

It looks like need to do some calculation

vyos@vyos:~$ show version | match Version
Version:          VyOS 1.3-rolling-202011130217
vyos@vyos:~$ show date 
Fri 13 Nov 2020 07:18:44 AM UTC
vyos@vyos:~$ reboot in 60
Invalid time "60". The valid format is HH:MM
vyos@vyos:~$ reboot in 59
Reboot is scheduled 2020-11-13 08:18:04
vyos@vyos:~$ reboot in 61
Invalid time "61". The valid format is HH:MM

Tested on 1.3-rolling-202011130217, all works as expected.
Thanks to @ernstjo

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

I believe this may be related to the following error messages I have:

Docuemntation from: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-tool_reference-tuned_adm

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

Sure—if you want to drop me an image I can try it out. I do have a working vyos-build as well, I can also try and produce my own with that change backed out when I get some time towards the end of the week.

@lucasec of course this commit could be related and we can try revert back to the old version. Would you be willing in testing a binary for us?

Put in a PR to add miscellaneous MPLS and LDP parameters.

I will perform a few additional tests tomorrow with the oldest available rolling releases (looks like October 13th as of writing). Will see if I can binary search my way to when things broke.

A few updates... the failure still occurs on latest rolling. Similar outcome—the kernel panics and dumps a stacktrace during the initial boot-up configure process. However, this issue goes back further than I expected (and initially expressed in the ticket). I goofed up in my testing of 1.3-rolling-202010260327 by booting with a default config file without the QAT option.

As discussed in Slack channel, these leftover processes should be cleaned up the next time configuration mode is entered (by UnionfsCstore::setupSession). In my limited testing, I can reproduce the leftover processes as above, but they are cleaned up the next time I enter config mode. There may well be corner cases where this mechanism is not successful, but I have not reproduced.

Put in a PR to add targeted LDP neighbors.

as we rely on OpenNHRP this looks like a dead end as of now. Maybe IPv6 support will get introduced and supported when we can migrate to FRR based NHRP - there is another task about that (T2326).

for reference:
my PIM config for allowing multicast from eth1.112 to eth1 (10.10.10.10 is a fictional ip):

show protocols pim 
 interface dum0 {
 }
 interface eth1 {
 }
 interface eth1.112 {
 }
 rp {
     address 10.10.10.10 {
         group 224.0.0.0/4
     }
 }

terminating watchfrr and pimd has solved the problem.
With my configuration everything was OK...

Your referenced commit is only relevant for validation logic if your hardware supports QAT or not. We now run Kernel 4.19.155 - please retry with the latest rolling release.

@tuxnet maybe this will help: https://docs.vyos.io/en/latest/routing/multicast.html

@christophedc0 Could you provide me with your pim configuration? i am not getting any further

set interfaces ethernet eth2 dhcp-options no-default-route

Available via set interfaces ethernet eth0 dhcp-options host-name

Issue is fixed in the latest rolling release. The IPv4 remote-host hostname in client mode works without adding the option '--proto udp4'.
Tested in VyOS 1.3-rolling-202011060217