PR for Equuleus https://github.com/vyos/vyos-1x/pull/959
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Aug 10 2021
Aug 10 2021
Aug 9 2021
Aug 9 2021
Unknown Object (User) added a comment to T3731: verify_accel_ppp_base_service return wrong config error for SSP.
Unknown Object (User) changed the status of T3731: verify_accel_ppp_base_service return wrong config error for SSP from Open to In progress.
Unknown Object (User) created T3731: verify_accel_ppp_base_service return wrong config error for SSP.
Viacheslav changed the status of T3730: op-mode conntrack-sync miss some functions from Open to Needs testing.
c-po closed T3720: IPSec set vti secondary address cause interface disable, a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, as Resolved.
GitHub <noreply@github.com> committed rVYOSONEX3203f2a6d495: Merge pull request #958 from sever-sever/T3730 (authored by jestabro).
- Backport configquerry.py [Done]
https://github.com/vyos/vyos-1x/commit/2aa75521a829712256c3c34685e60a9d36b33791
Need to implement in customer, if I can help in something, please don't hesitate to ask.
Maybe with FRR 8.1
In any case, we'll do more tests.
jestabro added a project to T3402: Add VyOS programming library for operational level commands: VyOS 1.3 Equuleus.
It's upgrade on FRR planned?
UnicronNL closed T1501: VPN Commit Errors, a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, as Resolved.
https://github.com/vyos/vyatta-cfg-vpn/commit/2cec760601a6e85ca8e0b6a30c173196a97a777a
Back-ported the dhcp ip check loop to 1.3
dmbaturin renamed T3729: Split the image build and config load smoke test into separate jobs from Separate the image build and config load smoke test into separate jobs to Split the image build and config load smoke test into separate jobs.
dmbaturin committed rVYOSONEXe737bac9fc8c: dhcp-server: T2432: Run dhcpd in group vyattacfg to allow recreate lease files (authored by Unknown Object (User)).
In T3728#99683, @Viacheslav wrote:It is possible this bug.
https://github.com/FRRouting/frr/issues/9181
It is possible this bug.
https://github.com/FRRouting/frr/issues/9181
Take a look to:
Viacheslav added a comment to T3537: Unable to override the default OSPFv3 link cost for wireguard interface.
@dtoux Did you test it in 1.3.0-rc5?
@xrobau As I mentioned before, peer-group can't exist without peer-as/remote-as in your case remote-as should be internal. It can exist without remote-as but with "route-reflector-client" it shouldn't
You can check it with vtysh FRR:
Unknown Object (User) closed T2776: QAT acceleration not working for IPSec AES-128 (CBC) / SHA256 tunnel as Invalid.
Unknown Object (User) added a comment to T2776: QAT acceleration not working for IPSec AES-128 (CBC) / SHA256 tunnel .
Tested on 1.3-rc5, all works properly
set vpn ipsec esp-group ESP_DEFAULT compression 'disable' set vpn ipsec esp-group ESP_DEFAULT lifetime '3600' set vpn ipsec esp-group ESP_DEFAULT mode 'tunnel' set vpn ipsec esp-group ESP_DEFAULT pfs 'dh-group19' set vpn ipsec esp-group ESP_DEFAULT proposal 10 encryption 'aes128' set vpn ipsec esp-group ESP_DEFAULT proposal 10 hash 'sha256' set vpn ipsec ike-group IKEv2_DEFAULT close-action 'none' set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection action 'hold' set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection interval '30' set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection timeout '120' set vpn ipsec ike-group IKEv2_DEFAULT ikev2-reauth 'no' set vpn ipsec ike-group IKEv2_DEFAULT key-exchange 'ikev2' set vpn ipsec ike-group IKEv2_DEFAULT lifetime '10800' set vpn ipsec ike-group IKEv2_DEFAULT mobike 'disable' set vpn ipsec ike-group IKEv2_DEFAULT proposal 10 dh-group '19' set vpn ipsec ike-group IKEv2_DEFAULT proposal 10 encryption 'aes128' set vpn ipsec ike-group IKEv2_DEFAULT proposal 10 hash 'sha256'
Flow served QAT
vyos@R2-QAT# run show system acceleration qat device qat_dev0 flows +------------------------------------------------+ | FW Statistics for Qat Device | +------------------------------------------------+ | Firmware Requests [AE 0]: 60046 | | Firmware Responses[AE 0]: 60046 | +------------------------------------------------+ | Firmware Requests [AE 1]: 112720 | | Firmware Responses[AE 1]: 112720 | +------------------------------------------------+ | Firmware Requests [AE 2]: 219657 | | Firmware Responses[AE 2]: 219657 | +------------------------------------------------+ | Firmware Requests [AE 3]: 60046 | | Firmware Responses[AE 3]: 60046 | +------------------------------------------------+ | Firmware Requests [AE 4]: 112722 | | Firmware Responses[AE 4]: 112722 | +------------------------------------------------+ | Firmware Requests [AE 5]: 219657 | | Firmware Responses[AE 5]: 219657 | +------------------------------------------------+
Interrupts
vyos@R2-QAT# run show system acceleration qat interrupts 140: 44039 0 0 0 0 0 0 0 IR-PCI-MSI 524288-edge qat0-bundle0 141: 0 42358 0 0 0 0 0 0 IR-PCI-MSI 524289-edge qat0-bundle1 142: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524290-edge qat0-bundle2 143: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524291-edge qat0-bundle3 144: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524292-edge qat0-bundle4 145: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524293-edge qat0-bundle5 146: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524294-edge qat0-bundle6 147: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524295-edge qat0-bundle7 148: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524296-edge qat0-bundle8 149: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524297-edge qat0-bundle9 150: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524298-edge qat0-bundle10 151: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524299-edge qat0-bundle11 152: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524300-edge qat0-bundle12 153: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524301-edge qat0-bundle13 154: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524302-edge qat0-bundle14 155: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524303-edge qat0-bundle15 156: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524304-edge qat0-ae-cluster
Unknown Object (User) committed rVYOSONEXc3d536f77d62: openconnect: T3695: Add systemd service checker on commit.
GitHub <noreply@github.com> committed rVYOSONEX8709e3561f1d: Merge pull request #957 from DmitriyEshenko/1x-equuleus-09082021 (authored by dmbaturin).
Unknown Object (User) changed the status of T3695: OpenConnect reports commit success when ocserv fails to start due to SSL cert/key file issues from Open to Needs testing.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/957
Viacheslav closed T2606: ikev2 mobike commit failed , a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, as Invalid.
I closed it. Can't reproduce it.
Re-open it if necessary. Just attach your vpn configuration.
Viacheslav updated the task description for T3727: VPN IPsec ESP proposal and ESP presented in config missmatch.
The same task T1375
Aug 8 2021
Aug 8 2021
c-po renamed T3318: Update Linux Kernel to v5.4.208 / 5.10.142 from Update Linux Kernel to v5.4.135 / 5.10.53 to Update Linux Kernel to v5.4.139 / 5.10.57.
c-po added a comment to T2027: get_config_dict is failing when the configuration section is empty/missing.
>>> from vyos.config import Config
>>> conf = Config()
>>> conf.get_config_dict(['service', 'ssh'])
{'ssh': {'disable-host-validation': {}, 'port': ['22']}}
>>> conf.get_config_dict(['service', 'non-existing'])
{}UnicronNL closed T169: Image install should put correct serial console device in created GRUB menu entry, a subtask of T2452: Serial console related issues, as Resolved.
UnicronNL closed T169: Image install should put correct serial console device in created GRUB menu entry as Resolved.
Checks the grub config rule by rule if ttyS/ttyUSB is used then updates the newly to be included grub template to the same.
dmbaturin changed the status of T169: Image install should put correct serial console device in created GRUB menu entry, a subtask of T2452: Serial console related issues, from Open to Needs testing.
dmbaturin changed the status of T169: Image install should put correct serial console device in created GRUB menu entry from Open to Needs testing.
GitHub <noreply@github.com> committed rVYOSONEX293c31785abe: Merge pull request #956 from Cheeze-It/current (authored by c-po).
c-po committed rVYOSONEX92db99f8e21b: ping: T3634: Fixing do not fragment to Ping (authored by Cheeze_It).
erkin added a project to T1161: Does Vyos take advantage of linux's improved security features?: VyOS 1.4 Sagitta.
Aug 7 2021
Aug 7 2021
I'm also affected by this. My configuration has about 5k ip prefixes in network group for policy based routing.
Cheeze_It added a comment to T3634: Add op command option for ping for do not fragment bit to be set.
Did more checks.....and noticed it *IS* properly sending the ping command:
I see these error in the openvpn log:
I don't think so the configuration is working, the interface is down. It is not assigning the ipv6 addresses to the tunnel interfaces.
dmbaturin closed T66: IPSec v6 over v6 support, a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, as Resolved.
It was enabled by commit https://github.com/vyos/vyatta-cfg-vpn/commit/993f5bf9f54bcb7af20d44e7618586b55064a372 quite a while ago and no one complains, so I assume it's not an issue anymore.
Aug 7 2021, 7:52 AM · Restricted Project
dmbaturin edited projects for T66: IPSec v6 over v6 support, added: Restricted Project; removed VyOS 1.2 Crux (VyOS 1.2.9), test, VyOS 1.3 Equuleus.
Aug 7 2021, 7:52 AM · Restricted Project
dmbaturin removed projects from T3712: route-map comm-list can't be used without option delete: VyOS 1.2 Crux (VyOS 1.2.9), VyOS 1.3 Equuleus, test.
It's not a bug, it's simply a weird syntax. That command could never be used without the delete option, so your config example wouldn't work in 1.2 or 1.1.8 either.
Aug 6 2021
Aug 6 2021
You COULD have a peer-group without remote-as, as you could apply that peer group to multiple remotes, and override the remote-as. But that is an edge case. The BETTER way to handle it is to enforce having a remote-as -- especially if you enable route-reflector-client
salt-minion in the debian buster tree is version 2016.11.2+ds-1+deb9u4
Seems like the repo's not needed anymore as my iso just built without it, twice, after a clean, and with a bunch of added stuff (tor, docker, systemd-nspawn, xtables-addons, hardened-malloc, a grsec kernel, etc) for which dependencies are also available without it.
Either way, probably a good idea to keep deps for anything third-party in the vyos repo itself since third parties can become hostile through buyouts or license changes any time and anywhere in these post-FOSS times.
salt-minion which depends on salt-common which may depend on a couple of other things:
What packages are we actually pulling from there? Any reason they're not in the VyOS repo itself?
I removed their repo entirely from the JSON config and my image built fine (apparently i now have to add a /debian suffix for all packages in our repo, but that's weirdness in the repo management stack):
Reading package lists... Building dependency tree... Reading state information... [2021-08-06 21:39:40] lb source P: Source stage disabled, skipping P: Build completed successfully
The procedure I usually end up using:
https://repo.saltproject.io/py3/debian/10/amd64/latest buster Release looks wrong - shouldn't it read main at the end, instead of Release?
Trying to use their instructions from https://repo.saltproject.io/#debian i'm back to the certificate issue - repo is set to https://repo.saltproject.io/py3/debian/10/amd64/latest buster main and the custom GPG key has been added, but certificate checks still fail hard:
Reading package lists... W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/InRelease: No system certificates available. Try installing ca-certificates. W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/Release: No system certificates available. Try installing ca-certificates. E: The repository 'https://repo.saltproject.io/py3/debian/10/amd64/latest buster Release' does not have a Release file. E: An unexpected failure occurred, exiting... P: Begin unmounting filesystems... P: Saving caches... Reading package lists... Building dependency tree... Del nftables 0.9.6-1 [66.8 kB]
After cleaning the chroot and retrying, it now fails utterly with the '#' in there:
Thanks! This is definitely a non-issue then, closing.
Since we cannot update the kernel in 1.3 due to the QAT issues, we likely need to backport netmap support. It seems to have been introduced by this commit: https://github.com/torvalds/linux/commit/3ff7ddb1353da
@maznu
Add these lines:
Thank you for pointing that out - updated defaults.json and it seems to have made that issue go away.
For some reason its now breaking on using our internal repo (no TLS there, inside the datacenter), but i suspect its got something to do with the repo itself or some change in Debian since we started using it.
dmbaturin changed the status of T1083: Implement persistent/random address and port mapping options for NAT rules, a subtask of T2198: Rewrite NAT in new XML/Python style, from Open to Needs testing.