Just as another data-point - I have found that leaving the DHCP lease to auto-renew itself (not me doing it manually) that it doesn't then add it to the routing table.
i.e. at the moment my DHCP client is still connected, but there's no default via the DHCP session at the moment.

Closed invalid - this is done with nftables now.

No, this isn't required in 1.4, the script I was using isn't compatible with nftables and the built in support for GeoLocation enabled services is a better solution.
This one can be closed as well, thanks.

Sorry guys - I'm on 1.4-epa2 these days but aren't doing VRRP/Conntrack sync anymore.

line 107: available_images: list[str] = annotated_list(grub.version_list())
Should be: available_images: list[str] = grub.version_list()

This is still an issue for 1.4.0-epa2.

Does the problem only appear after your 5am reboot every day?

Thanks Team! Luv Ya!

I stopped using conntrack-sync before I moved to 1.3 (which I am currently running) so I can't confirm either way.
I expect it's no longer an issue though and this task can be closed.

Forgot to ever reply to this - I just wanted it added as a standard debian package so that scripts that depend on it can have it available without needing to be installed seperately.

Think this can be closed - there's no such command in 1.3 is there?

This is on a virtio interface:

Simple reproducer - doesn't need to be an upgrade, just apply this to 1.4

Things to note that I'm not sure if they play a part:

Furher to this, manually setting "mru 1500" gives me my 1500 MTU back again.

The new MRU config in 1.3.4 seems to have caused my MTU to be lower.

I also notice looking at the backup after another reboot:

I hate to drag up an old ticket, but I've just encountered this issue.
A freshly built VyOS 1.3-rolling-202209010158

I can confirm this has been the reason I've had issues upgrading from 1.2.x to 1.3.x.
Removing this statement before attempting, I can now upgrade from 1.2 to 1.3 smoothly, no OOM errors or other problems.

This is still an issue with 1.2.7-epa1

This is still a problem, I have just upgraded from 1.2.6-S1 to 1.2.7-epa1 and had two conntrackd's running on the primary router.

This is now fixed in 1.2.7-epa1

So I have found a workaround/fix for this.

Same issue. I'm happy to send my config file (not publically) for further debug if that'll help?

Sure thing, I'll try it again tomorrow.

Is there anything else I can do to help debug this issue?

I just saw the patch above for how to fix this and yes, with that line changed to sudo it now works correctly.
Thanks!

Additionally, it only happens after a system image upgrade - it doesn't seem to happen if you reboot again after that.

So I just hit this bug again upgrading from 1.2.6-epa1 to 1.2.6.

So I fixed this on my setup by kill -9 conntrackd
and then sudo /etc/init.d/conntrackd start

Hmmm is it the fact I have a remote syslog configured that triggers this bug?
I didn't realise that, I'll have to remove it and see if it helps.
It's very frustrating not having the firewall logs available to view.

For what little to no weight my opinion matters, I also agree that this should be backported to Crux.
As I've bashed my head into it testing :-)

@jjakob No, it's not logged in the journal either:

Some other people reporting similar here.

I'm seeing this in Vyos 1.2.5 just released:

I've just encountered this bug with Vyos 1.2.5 (final, official ISO)

It would appear this commit is the source of the problem - client-config-dir was removed but I don't see anywhere it's re-added.

Thank you @c-po - I can confirm removal of connect-on-demand fixes the problem.
I was under the, obviously mistaken, impression that I needed that command for PPPoE to self-establish on reboot. But I obviously don't as I've just rebooted with the latest 1.3-rolling-202004090909 and it's connected straight away and is working.

Please find below, with some comments redacted.

The only major differences I've noticed are the kernel versions: