Please test again with the rolling release from 2019-09-14. Thanks for reporting the issue.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Sep 13 2019
Sep 13 2019
hagbard moved T1597: /usr/sbin/rsyslogd after deleting "system syslog" from In Progress to Finished on the VyOS 1.3 Equuleus board.
hagbard added a comment to T1655: equuleus: buster: arm: vyos-accel-ppp build failes because of filename hardcoded as x86_64 in debian/rules.
pushed to current too and rebuilt kernel in CI successfully.
hagbard reassigned T1660: Bonding dont’t work on VyOS 1.2-rolling-201909120338 from hagbard to Unknown Object (User).
GitHub <noreply@github.com> committed rVYOSONEX213213a4c007: Merge pull request #128 from DmitriyEshenko/patch-8 (authored by hagbard-01 <39653662+hagbard-01@users.noreply.github.com>).
Unknown Object (User) added a comment to T1660: Bonding dont’t work on VyOS 1.2-rolling-201909120338.
hagbard changed the status of T1655: equuleus: buster: arm: vyos-accel-ppp build failes because of filename hardcoded as x86_64 in debian/rules, a subtask of T476: Update the base system to Debian 10 (Buster), from In progress to Needs testing.
hagbard changed the status of T1655: equuleus: buster: arm: vyos-accel-ppp build failes because of filename hardcoded as x86_64 in debian/rules from In progress to Needs testing.
@runar
I just cross compiled it successfully. CI uses a sed right now to correct it, all paths are now generic.
What I currently can't do is actually testing the binaries on a real device, I would appreciate it if you can do that.
Unknown Object (User) created T1659: SPAM.
This is a support request,
please use forum.vyos.io for such request
Sep 12 2019
Sep 12 2019
GitHub <noreply@github.com> committed rVYOSONEX5d432809cb44: Merge pull request #127 from DmitriyEshenko/l2tp-op_mode (authored by hagbard-01 <39653662+hagbard-01@users.noreply.github.com>).
Unknown Object (User) added a comment to T834: New L2TP server implementation based on accel-ppp.
@drac , before implementation cli command for restarting l2tp I need explanation how to reproduce issue when daemon is died. Can you detailed explain this?
Unknown Object (User) added a comment to T834: New L2TP server implementation based on accel-ppp.
Implementation advanced ppp-options
vyos@vyos# set vpn l2tp remote-access ppp-options
Possible completions:
lcp-echo-failure
Maximum number of Echo-Requests may be sent without valid reply
lcp-echo-interval
LCP echo-requests/secGitHub <noreply@github.com> committed rVYOSONEX87bcec2732c8: Merge pull request #126 from DmitriyEshenko/l2tp-op_mode (authored by hagbard-01 <39653662+hagbard-01@users.noreply.github.com>).
Unknown Object (User) added a comment to T834: New L2TP server implementation based on accel-ppp.
@drac, thank you for info.
reset commands migrated to vyos-1x, PR bellow
https://github.com/vyos/vyatta-ravpn/pull/13
https://github.com/vyos/vyos-1x/pull/126
I'm thinking about trying to run either tayga or jool as a docker container inside of VyOS. Has anyone tried something like this? If I wrote a guide on how to do this I wonder if it would be an OK temporary solution until it's integrated into VyOS.
hagbard changed the status of T1655: equuleus: buster: arm: vyos-accel-ppp build failes because of filename hardcoded as x86_64 in debian/rules, a subtask of T476: Update the base system to Debian 10 (Buster), from Open to In progress.
hagbard changed the status of T1655: equuleus: buster: arm: vyos-accel-ppp build failes because of filename hardcoded as x86_64 in debian/rules from Open to In progress.
runar placed T1656: equuleus: buster: arm: iso creation failes because of intel drivers up for grabs.
runar triaged T1656: equuleus: buster: arm: iso creation failes because of intel drivers as Normal priority.
syncer closed T534: VPN/IPSEC/BGP/DPD - unknown bug, tunnel and interfaces up, but no traffic as Wontfix.
Ok, closing as wontfix
c-po added a parent task for T1466: Add EAPOL login support: T1637: Rewrite ethernet interface in new style XML syntax.
c-po added a subtask for T1637: Rewrite ethernet interface in new style XML syntax: T1466: Add EAPOL login support.
mario added a comment to T534: VPN/IPSEC/BGP/DPD - unknown bug, tunnel and interfaces up, but no traffic.
No, we don't use vyos in production any more, so I can't tell.
We have openned a ticket on VyOS support, and they have find the solution.
We had to add this configuration :
syncer triaged T1654: sFlow: multiple "sflow server" not work, and "disable-imt" could break configuration as Low priority.
syncer edited projects for T1654: sFlow: multiple "sflow server" not work, and "disable-imt" could break configuration, added: VyOS 1.3 Equuleus, VyOS 1.2 Crux (VyOS 1.2.4); removed VyOS 1.2 Crux.
Sep 11 2019
Sep 11 2019
dmbaturin renamed T1460: "show firewall ...." doesn't support counters with more than eight digits from "show firewall ...." does not show information correctly in specific cases to "show firewall ...." doesn't support counters with more than eight digits.
dmbaturin renamed T1362: Incorrect handling of special characters in VRRP passwords from VRRP Auth Password Is Not Sanitized - to Incorrect handling of special characters in VRRP passwords.
@rcit Is that still a relevant issue?
nothing added we would need.
dmbaturin changed the status of T1642: BGP configuration error when using remove-private-as from Open to Needs testing.
I have been trying this new feature out.
- I had configured an MTU value and I had some sessions connected, I realised I had set it incorrect so I modified it to the correct value. On commit I received an error (sorry I don't have it at present) but to the extent that accel-pppd was not running on localhost:2004.
I had to reboot the router to get it working again.
hagbard changed the status of T770: Bonded interfaces get updated with incorrect hw-id in config. from Confirmed to In progress.
isithran awarded T31: Add VRF support a Like token.
Unknown Object (User) added a comment to T1545: IPSEC vti issue.
Helo, @MarcSim. I want reproduce your issue in lab, can you provide your ipsec configuration from Central VyOS and one of site
show configuration commands | match ipsec | strip-private
zsdc changed the status of T1654: sFlow: multiple "sflow server" not work, and "disable-imt" could break configuration from Open to Confirmed.
@alkersan I think you need to create the link via Makefile in vyos-1x. At least I don't know of any possibility doing that within the xml.
hagbard added a comment to T534: VPN/IPSEC/BGP/DPD - unknown bug, tunnel and interfaces up, but no traffic.
Thanks for your response, did you test a newer image already? There was a lot of work done meanwhile.
mario added a comment to T534: VPN/IPSEC/BGP/DPD - unknown bug, tunnel and interfaces up, but no traffic.
tried with the first version 1.2, problem was still present. After that, decided to get us a physical router/fw because ipsec would stopped without any obvious reason.
It was a long time ago, almost year and a half...
Sep 10 2019
Sep 10 2019
hagbard moved T1597: /usr/sbin/rsyslogd after deleting "system syslog" from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
hagbard moved T1597: /usr/sbin/rsyslogd after deleting "system syslog" from Needs Triage to Backlog on the VyOS 1.2 Crux (VyOS 1.2.4) board.
@mario Did you manage to upgrade to 1.2 and if so, do you still have that issue?
hagbard changed the status of T1597: /usr/sbin/rsyslogd after deleting "system syslog" from Open to Needs testing.
hagbard changed the status of T1395: Improve boot time for instances with a big count of DHCP servers from In progress to On hold.
hagbard closed T1649: feature documentation different keypairs per interface , a subtask of T1572: Wireguard keyPair per interface, as Resolved.
hagbard closed T1650: implement wireguard default key removal, a subtask of T1572: Wireguard keyPair per interface, as Resolved.
hagbard changed the status of T1650: implement wireguard default key removal, a subtask of T1572: Wireguard keyPair per interface, from Open to In progress.
hagbard changed the status of T1650: implement wireguard default key removal from Open to In progress.
hagbard changed the status of T1649: feature documentation different keypairs per interface , a subtask of T1572: Wireguard keyPair per interface, from Open to In progress.
hagbard changed the status of T1649: feature documentation different keypairs per interface from Open to In progress.
hagbard closed T1648: add cli command 'delete wireguard named-key <key>', a subtask of T1572: Wireguard keyPair per interface, as Resolved.
hagbard changed the status of T1572: Wireguard keyPair per interface from In progress to Needs testing.
https://github.com/vyos/vyos-1x/commit/1017c8103f12ebd6db4f250d8a154571fff32db1
Will be available in tomorrows rolling release for testing. Documentation is underway.
Why can I not delete the default key? If I wan‘t to drop WireGuard on a device I also wan’t to remove that key.
hagbard changed the status of T1648: add cli command 'delete wireguard named-key <key>', a subtask of T1572: Wireguard keyPair per interface, from Open to In progress.
hagbard changed the status of T1648: add cli command 'delete wireguard named-key <key>' from Open to In progress.
The default keys can only be overwritten, named-keys can be removed.