In the example above you only included the header, could you extend the examples with example information you want to display there?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 15 2020
Resolved as informed by @tuxnet
If you do not change show int, you can output the specific information of vlan id in the command show interfaces bridge vlan
Ungortunately this is a -1 from me.
Possible reason - ipset should be converted to nft list set
This will be resolved / migrated away in T3048.
We have a basic implementation available. Additional changes should be submitted via feature requests.
Nov 14 2020
VyOS 1.2 adds a random link-local address on tunnel interfaces by default.
Now there is a new plan, please see T3071
Now there is a new plan, please see T3071
@runar The latest image already supports VLAN aware bridge, so this task list can be closed
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.
Nov 13 2020
@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.
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:
I have written an "fast" fix until tunnel is rewritten. Can you test it?
@ernstjo yeah we also have this "situation" with wireguard tunnels. Should be fixed in general with the rewrite of tunnel to get_config_dict() which is the second last interface not using this scheme, vti is last.
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
I believe this may be related to the following error messages I have: