I‘d rather suggest building a test iso as we build the frr source code from their repo directly. I would not permanently add this not yet mainlined patchset to the package feed
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Jul 31 2019
Jul 31 2019
Unknown Object (User) changed the status of T1555: l2tp: LNS features implementation from Open to In progress.
jestabro closed T1553: equuleus: buster: add 'noautologin' to boot parameters, a subtask of T476: Update the base system to Debian 10 (Buster), as Resolved.
Can we make a nightly with the patches from:
Jul 30 2019
Jul 30 2019
hagbard moved T853: Add SSTP server support from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
hagbard moved T1552: accel-ppp: SSTP documentation from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
hagbard moved T1351: accel-pppoe adding CIDR based IP pool option from Needs Triage to Backlog on the VyOS 1.2 Crux (VyOS 1.2.2) board.
hagbard reassigned T834: New L2TP server implementation based on accel-ppp from hagbard to Unknown Object (User).
hagbard moved T1536: PPPoE "Terminating on signal 15" from Need Triage to Backlog on the VyOS 1.2 Crux board.
hagbard changed the status of T853: Add SSTP server support, a subtask of T742: Replace poptop and xl2tpd with accel-ppp, from In progress to Needs testing.
Details of the mechanism, introduced after jessie, are in
jestabro changed the status of T1553: equuleus: buster: add 'noautologin' to boot parameters from Open to In progress.
c-po changed the status of T1550: Add support for Large BGP Community show commands from Open to Needs testing.
https://github.com/vyos/vyatta-op-quagga/pull/3 I hope now it looks better
Did I something wrong with https://phabricator.vyos.net/T1550 and https://github.com/vyos/vyatta-op-quagga/pull/2 that the pull request is not showing in phabricator?
Unknown Object (User) created T1551: Error when creating QinQ interface without earlier sets firewall name, if it used in the S1 VyOS Public space.
Jul 29 2019
Jul 29 2019
dmbaturin closed T1532: [equuleus] buster: GPG error on vyos package repository, a subtask of T1132: Build on Debian Buster, as Resolved.
I've fixed the setup and re-populated the equuleus repo.
hagbard added a project to T1351: accel-pppoe adding CIDR based IP pool option: VyOS 1.2 Crux (VyOS 1.2.2).
https://github.com/FRRouting/frr/pull/4742 let's give it a try?
Jul 28 2019
Jul 28 2019
Jul 27 2019
Jul 27 2019
Confirm fixed in latest rolling 201907270337
Confirm fixed in latest rolling 201907270337
Jul 26 2019
Jul 26 2019
c-po changed the status of T1548: Rewrite OpenVPN interface/op-commands in new style XML/Python from Open to In progress.
prototype successfully tested
hagbard reassigned T1546: accel-ppp/L2TP radius-source address is not honored from hagbard to Unknown Object (User).
That error will disappear once https://github.com/vyos/ppp-upstream/pull/1 has been merged in. You can meanwhile try to remove the route option and see if it makes any difference.
All of VyOS is VMs hosted on ESXI
thinkl33t added a comment to T1416: 2 dhcp server run in failover mode can't sync hostname with each other.
Yeah, I'd mark this not-a-bug. Update the documentation to mention hosts file update with failover doesn't maintain consistent state between failover servers.
Sorry about the delays, been a couple hectic days at work.
Jul 25 2019
Jul 25 2019
c-po moved T1526: [SNMP] write documentation for snmp script extension from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.3) board.
c-po moved T1541: Error when committing dhcpv6-relay configuration. from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.3) board.
c-po edited projects for T1541: Error when committing dhcpv6-relay configuration., added: VyOS 1.2 Crux (VyOS 1.2.3); removed VyOS 1.2 Crux.
@mustard Any updates?
hagbard changed the status of T834: New L2TP server implementation based on accel-ppp, a subtask of T833: New PPTP server implementation based on accel-ppp, from In progress to Needs testing.
hagbard changed the status of T834: New L2TP server implementation based on accel-ppp from In progress to Needs testing.
Attached are the pcap and debug logs from a simple setup as outlined above, two hosts. "Master" distributing the route.
dmbaturin updated the task description for T1543: Add a source address/interface option for commit archive connections.
dmbaturin triaged T1543: Add a source address/interface option for commit archive connections as Normal priority.
dmbaturin edited projects for T1542: static-host-mapping entries broken after reboot, added: VyOS 1.2 Crux (VyOS 1.2.3); removed VyOS 1.2 Crux.
I could reproduce it. The DHCP client script overwrites those entries.
Some Feedback from the frr people:
Thanks - but still there should not be a Python error and also a user error message
Got it to work correctly by adding the address of the listen-interface onto eth0
Jul 24 2019
Jul 24 2019
currently testing internally, will be released soon to the current branch.
With the new versions of the open-vm-tools you can explicitly disable the pulling of the routing-table. Maybe that's a better way then disabling the whole pulling of information.
Tested rolling from yesterday and 1.2.2, no issues.
@c-po Still not fully resolved on Crux . Maybe candidate for Backlog on VyOS 1.2.3? Thanks.
@mustard Your ppp session looks just fine. The removal of your default route doesn't terminate the pppoe connection, at least there was no termination request in the dump. Your icmp echo request time out since you don't have a default gateway, so we need to find out why the default gateway gets removed. When you see the icmp timeouts for 8.8.8.8 your pppoe session is still alive and is answering the LCP requests successful, so I think we need to focus on frr and why it is removing the efault route.
The following log lines are produced when the disconnect occurs
Unknown Object (User) added a comment to T1536: PPPoE "Terminating on signal 15".
Hello @mustard . Can you provide logs when route deleted?
show log tail 50
I enabled debug in /etc/ppp/options and all seems to be ok with the underlying PPPoE connection but I still loose the connection. I think the default route is being dropped some how?
Thanks for trying to reproduce the issue,
Jul 23 2019
Jul 23 2019
hagbard added a comment to T611: Static route syntax should reflect `ip` command routing capabilities, if possible..
personally I like the below most. it will require quite an amount of work for migration.
See T1331
c-po moved T1425: No longer able to assign a /31 address on Wireguard interface from Backlog to Finished on the VyOS 1.2 Crux (VyOS 1.2.3) board.
backported
hagbard moved T1450: crux: ping * flood is not working from Backlog to Finished on the VyOS 1.3 Equuleus board.
hagbard moved T1450: crux: ping * flood is not working from Need Triage to Backlog on the VyOS 1.3 Equuleus board.
hagbard moved T1450: crux: ping * flood is not working from Needs Triage to Backlog on the VyOS 1.2 Crux (VyOS 1.2.3) board.
hagbard changed the status of T1450: crux: ping * flood is not working from Open to Backport candidate.
has been fixed by reverting to 4.1 since pdns stopped supporting debian jessie.
hagbard changed the status of T853: Add SSTP server support, a subtask of T742: Replace poptop and xl2tpd with accel-ppp, from Open to In progress.
Run into the same with 1.2.2