On the fresh version builded today:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 20 2019
Aug 19 2019
Aug 17 2019
Aug 16 2019
Maybe you could comment on this @zx2c4 ?
I think we should use it as a chance to improve it. The nesting does not do anyone any favors, tcpdump applies to all interface type, so a single level "monitor interface $intf" command is going to be easier to use.
Aug 15 2019
[e]ach network interface has a private key [...]
@hagbard It's not stated that you MUST use a new private key for each interface. But it states that
[e]ach network interface has a private key [...]
https://www.wireguard.com/#simple-network-interface ⇒ Cryptokey Routing
to set a private key for each interface only makes sense when you are allowed to use different keys for different interfaces. If there would be any withdraw in using multiple keys they would have just omitted the "privateKey" in the config file and set i globally. Since they didn't do that I can't imagine there is one. But I would be interested in learning what withdraws you see that the developers don't see.
Aug 14 2019
Hello @hammersoft , VyOS migrated from xl2tp to accel-ppp. Can you check this issue on latest rolling?
https://phabricator.vyos.net/T834
Aug 13 2019
Why not use curl which is inside the image?
Aug 12 2019
Yes, sorry, I was mean about new syntax for rolling release. PR for fixing issue with ARP https://github.com/vyos/vyos-1x/pull/101
@Dmitry, thanks for reply.
Hello @olofl , I think you need show protocols static arp interface eth1.1728 command. You also may read about ARP on https://vyos.readthedocs.io/en/latest/routing/arp.html?highlight=show%20arp
Aug 9 2019
I don't think it's a good idea, for several reasons.
This sounds like a good improvement!
I second this, I would like to be able to setup different keys for multiple wireguard interfaces too.
Aug 6 2019
Aug 5 2019
Thanks for the info.
Added the following to /etc/ppp/ip-down
echo "IP Down $1 $2 $3 $4 $5 $6" >> /tmp/foo.log
Aug 3 2019
Created PR https://github.com/vyos/vyatta-cfg-quagga/pull/32. Problem with comparison types
Aug 1 2019
@dmbaturin
Confirmed: the problem is not reproducible anymore in 1.2.0-rolling+201908010337 with keepalived 1:2.0.17+vyos1.2.
@ekim, we have never met with such a problem and cannot reproduce it in our environments. The better way to continue investigation would be getting access to this installation. If this would be possible, we could continue debugging.
Jul 31 2019
Please test with tomorrows rolling release.
This is applicable for the Intel IGB and IXGBE drivers
Jul 30 2019
Jul 26 2019
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
Sorry about the delays, been a couple hectic days at work.
Jul 25 2019
@mustard Any updates?
I could reproduce it. The DHCP client script overwrites those entries.
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
Tested rolling from yesterday and 1.2.2, no issues.
@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
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 22 2019
Problem exists on 1.2.2
I can't reproduce your issue, so I suspect no issues with the pppoe client we ship in vyos.
Your filter was a bit to tight, all I see are the LCP echos. I' more interested in the PAD packets, in particular what sides sends a PADT and if PADS is clean.
Thanks for the reply,
Jul 21 2019
your are confused with client and server commands.
Jul 18 2019
We cannot backport anything that introduces a syntax or behaviour change, much less if it may possibly need a migration script. ;)
Even if it was allowed, dhcpd would fail to start with the generated config so it shouldn't be a problem? Unless some had their invalid config kept even with broken dhcp-server, which I doubt.
It would be fixed first in current, of course. It's not a priority for me so I won't be tackling it.
@zsdc I've included keepalived 2.0.17 in the rolling release repo and it will be in tomorrow's nightly build. Please test.