https://github.com/vyos/vyos-1x/commit/dcb9f521f9f6dbb98df8f644009c05342f596b5a

Looks like a race condition, since it is now being started by systemd as well, which was previously not the case.

But there was before a fully working one, anyway curl will work as well. Let's close this ticket then, was just bad communication I guess. I have found a few other issues, I'm currently looking into. Looks like netlink in the kernel changed, breaks netplug and pppoe-server. Thanks for pointing me into the right direction.,

Ah, now I see - yes this is correct, there is no "real" wget installed instead the BusyBox version is used. BusyBox is a multi-call binary (a lot of tiny helper programs shipped in one binary, program snipped is determined using argv[0] that's why every BusyBox binary is a symlink to /bin/busybox

wget https://downloads.vyos.net results in 'not an ftp or http url'

wget https://...
or if you check with ldd you'll see that it is only compiled against libc and that's it.

I can not reproduce the issue.

added not on old-style cfg-mode templates

Added a sidenote about switching on router and routing on switch

First commit on implementing this: https://github.com/runborg/vyatta-cfg-system/commit/15f6f2e06cc3e7d4e25f9cd381e70b8d978717f6

I'm not a fan of cluttering the OS too much, there are two much better ways

Relevant config:

Please retest on 1.2.1

@yun thanks
@dmbaturin Any idea how we can address this?
@hagbard closed request

In T1250#35137, @UnicronNL wrote:

@yun What is the exact frr command you tried?
the command you tried manually.

ok. @UnicronNL please reject my PR then. thx.

@yun What is the exact frr command you tried?
the command you tried manually.

@hagbard This commit adds a route to the kernel routingtable and bypassing FRR, this is no good and this would break. Please make the script add the appropiate commands to frr instead. This way frr will be in charge of populating the kernel table. Also note that this route needs to be removed on dhcp release

@hagbard that commit sets a kernel route. that is not good.

@yun it's only that single line.

Any news about this ?

I would to see this committed. But do we also know what causes the issue? Is it with FRR or was this script just missing the ip command to set the default gw?

With apologies (not having used Phabricator before), I think I may not have filed this bug report correctly. I also did not intend to "triage" it when filing it, as this should be done by a responsible adult! :-)

Assuming this works - please reopen if not

https://github.com/vyos/vyos-replace/pull/1 awaiting review, I have no commit privs.

Not sure if the l2tp/vti modification merits inclusion - that depends on personal configuration of which tunnel is inside the other. I think the original config is correct for the more common use case of having l2tp secured by ipsec.

Could you tell us the exact modifications? Or even better - send a Pull Request via GutHub so we could include it into VyOS.

That worked, thanks. Had to set it to 901, the vpn node was 900. Added a sed to the preconfig script so it survives updates.

@c-po accel-ppp is a server, the pppoe client in vyos is rp-pppoe, which causes the issue.
ppp works and Acks the IPv6 address:

@c-po, Accel-ppp support next option in [pppoe] section

You can try playing around with the priority in the l2tpv3 node.def files. Higher priority means its executer later. DHCP for instance uses 900-something.

I can confirm that as soon as IPv6 is enabled on pppoe0 the interface is no longer renamed from ppp0 to pppoe0.

I switched to a L2TPv3 tunnel for better performance than OpenVPN, still will not come up at boot if it depends on the vti interface.

@tomjepp please test

Probably not the most common config, but I already have IPSec tunnels between all my sites, but need the L2 bridge and ovpn's fragmentation for my TV STB to function correctly through a tunnel. Perhaps adding a depends-on-interface option to all interfaces would be the most generic way to resolve this. I will try and see how difficult this is to implement in the config scripts when I have some time in the next week or 2.

Curiously, I can't reproduce it in the latest rolling, even though the code hasn't changed. We need to test in latest crux builds.

The packages were out of sync with reality for some time. Should be fine now.

@tomjepp Could you share the patch or tell us what and where you had to modify?

Code is now merged, please test in the next rolling release tomorrow

i've updated the code to handle <, > and probably other special characters. for now its waiting a merge on current/rolling and needs testing when merged

Lets test it first :)

In T1309#34455, @runar wrote:

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

+1 on having this in 1.3 and not 1.2

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

seems so but: