@Maetthi Is that still an issue? You need an uplink first and the interface needs to be able to reach (route) the other side.

@alainlamar Can you please share some config data, so I can reproduce the issue.
thx

yes.
I tested once again with:
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201905230337-amd64.iso

Dear, if I download the image available today 05/23/2019, is it already with this fix?

Initial commit in fork; support for merging remote files still to be added.
https://github.com/jestabro/vyatta-cfg/commit/96a8f894686b43bbd7f52da8ded87562231cbf52
https://github.com/jestabro/vyos-1x/commit/a31de0d8e2164a6b0bc9a7b6c1e03c053635120b

There are many complexities with our deployments that force our hand for acceptable configuration paradigms. It might make more sense to discuss this directly via email like we did for the DHCP VTI/VPN features/bug fixes that are included in 1.2.1.

added ipv6-pd and ipv6 address to 'show pppoe-server sessions'

fixed and rebuilt.

Or if DNAT is a no go, use wireguard and tunnel it.

What about destination nat? (https://vyos.readthedocs.io/en/latest/nat.html#destination-nat) + binding it too loopback.

Our use case requires that the SSH listener be a public IP address (no NAT), of which we only get the one on the DHCP interface. As such, your suggestion will not work for us.

You can always let SSH listen to a loopback address

I met this issue before. But I can save firewall group to a txt then use ipset to load the firewall groups when system boot. It works well. Vyos boot quickly and firewall policy updated well.

Testing confirms that the default console speed is set to 115200 when the old migration scripts are removed, as they will be by

Thanks for testing.

@hagbard Looks good:

Thanks for testing it, I'll close the bug ticket then.

Fix is in the next rolling or via http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb available.

sucessfully tested with:

set service pppoe-server access-concentrator 'testevyos'
set service pppoe-server authentication local-users username test password 'test'
set service pppoe-server authentication mode 'local'
set service pppoe-server client-ip-pool start '192.168.96.177'
set service pppoe-server client-ip-pool stop '192.168.96.180'
set service pppoe-server client-ipv6-pool delegate-prefix '2104:db8:8003::1/48,56'
set service pppoe-server client-ipv6-pool prefix '2104:db8:8002::1/48,64'
set service pppoe-server dns-servers server-1 '192.168.66.13'
set service pppoe-server dns-servers server-2 '192.168.183.162'
set service pppoe-server dnsv6-servers server-1 '2001:4860:4860::8888'
set service pppoe-server interface 'eth2'
set service pppoe-server local-ip '192.168.96.28'

8472 is the default port used by the Kernel, and thus fully backwards compatible with older installations. 4789 is the IANA assigned value which you could configure using remote-port.

IMHO the only reasonable solution would be to git bisect the Kernel and find the commit which introduced the problem.

Just commenting, UEFI boot is now working (tested in hyper-v gen2 VM with 1.2 20190520). Personally, I care from a performance perspective: hyper-v gen2 network adapters greatly outperform the "legacy network adapter" available to gen1, which is a full software emulated NIC.

I'll check this tonight.

the commit success now in the latest rolling.

@sentania Can you please test with the latest rolling, the issue should have been fixed now.

I have just tested Kernel 5.1.2 which has a newer igb driver (version: 5.6.0-k) but still no go. Not really sure where to go next.

I'm noticing this issue while attempting a pxe boot to live install on the same chipset but for a quotom unit. Most data that covers this problem seems to point to the kernel being the culprit as previously indicated.

Confirmed fixed in vyos-1.2.0-rolling+201905210337

Confirmed fixed in vyos-1.2.0-rolling+201905210337

The place that limits it to only ethernet devices seems to be: https://github.com/vyos/vyatta-cfg-system/blob/crux/templates/interfaces/pseudo-ethernet/node.tag/link/node.def (the checking itself happens at https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/vyatta-interfaces.pl#L377)

I have prepared the change
https://github.com/mevertse/vyatta-cfg-quagga/commit/d3685f504e0c22a8c88899aebc1e8705637259c4

I want to build a setup like described in:

@rob Fix will be in next rolling release

https://github.com/vyos/vyatta-openvpn/commit/cdd5d072f5a722156a06e600b5742e8bc3854b55

Thank you @wsapplegate for the contribution. Please test with the next rolling release.

Thank you @wsapplegate for the contribution. Please test with the next rolling release.

We should not emit any warning at all - this was caused by a bug in the remote-port implementation.

I can't see 'unknown command' lines in log anymore, on VyOS 1.2.0-rolling"201905180337.

The above patch should fix the issue.

The above patch should fix the issue.

This patch should fix the issue.

@dmbaturin merge if it's not already there

Build Docker container two times on different machines (Linux host and macOS host) ... no problems detected. closing this.

Can't reproduce the issue using commit 217aa6afaeb of vyos-build repo

is that still an issue in the latest rolling image?