Fix build PR https://github.com/vyos/vyos-build/pull/450

PR https://github.com/vyos/vyos-build/pull/448

PR https://github.com/vyos/vyos-build/pull/445

https://github.com/vyos/vyos-1x/pull/2417

PR for 1.5 which will be backported to 1.4 https://github.com/vyos/vyos-1x/pull/2416

I don't see this fix having been backported to Equuleus.

I'm building 1.4 rolling with the ixgbe out-of-tree driver if anyone cares.

Instead of "deny all" if no allow-clients are configured then localhost is always allowed. Can be handy when using containers and other if needed to sync to localhost for whatever reason (if the use of RTC isnt enough).

This has been implemented in 1.5 and 1.4.

@Apachez this request stems from this issue: https://forum.vyos.io/t/evpn-vxlan-esi-lag-duplicate-packets/12581

Both single-active and all-active should be supported when it comes to EVPN Multihoming.

I believe it's probably generating this error because modem sends an empty hostname.

Logs from just dhclient.

I didn't update it since the initial report and I don't really understand how/why it's working again.

PR for 1.5 current https://github.com/vyos/vyos-1x/pull/2413 which will then also be backported to 1.4

I would still recommend you to try to test to put a L2-switch between your 5G-router and the VyOS box and see if that resolves the situation.

This functionality has also been backported to 1.4 so it will be in the next LTS release.

Original template /usr/share/vyos/templates/chrony/chrony.conf.j2 (just the allow and listen sections):

What kind of cleanup are you talking about?

Turns out that the output of bindaddress will be broken unless put in a loop even if a single entry the only allowed entry.

This task is regarding to add localhost by default as allowed source to speak to chronyd (the current NTP daemon in VyOS).

Since the root cause for this task have been identified and fixed by the reporting user (and the task is set to invalid) I have created another task for the spinoff regarding cleaning up of the template used by chronyd:

As it seems according to https://manpages.debian.org/bookworm/chrony/chrony.conf.5.en.html both bindaddress and binddevice can only be specified once.

Ahh yes, I think there is another task in here regarding adding firewall rules by default to the firewall to avoid situations like this :-)

I added the above modifications to /usr/share/vyos/templates/chrony/chrony.conf.j2 and rebooted VyOS 1.5-rolling-202310240118.

I found the issue. I was missing a firewall input rule to allow anything from lo.

With my config chronyd still listens locally on 323:

udp        0      0 192.168.2.253:123       0.0.0.0:*                           20420/chronyd
udp        0      0 127.0.0.1:323           0.0.0.0:*                           20420/chronyd
udp6       0      0 ::1:323                 :::*                                20420/chronyd

I havent been using ninja2 scripting previously but Im guessing something like this would be needed:

Here is the output of sudo ls -la /run/chrony (just booted up so drift will probably missing for some time):

Any docs or example on how bfd interacts with pim?

PR : https://github.com/vyos/vyos-1x/pull/2411

@Viacheslav yes, I already did last month, but there were lots of errors when veryfing the fix.
I figured it came due to the changes performed by task https://vyos.dev/T5048.

It is not, but I do not want to make my NTP internet-facing anyways.

Is your WAN interface also in net 192.168.0.0/16?

Can you show the output of sudo ls -la /run/chrony?

My VyOS NTP config:

set allow-client address '192.168.0.0/16'
set listen-address '192.168.2.253'
set server time.aws.com pool
set server time.google.com pool

PR created: https://github.com/vyos/vyatta-op/pull/79

PR created: https://github.com/vyos/vyatta-op/pull/79

How is your current ntp configuration (as outputed by show config commands)?

I would still recommend you to try to test to put a L2-switch between your 5G-router and the VyOS box and see if that resolves the situation.

One way however to make the variable more robust in case there are for whatever reason more than one squashfs mounted object available is to select the one who is "loop0".

Looking through https://vyos.dev/T5457 I now get what you meant by "re-broke it".

But before the revert by T5690 today T5440 worked perfectly fine so what was "re-broken"?

Nope, it works fine, now; your revision to the change re-broke it.

https://github.com/vyos/vyos-build/pull/441 PR has been created

Does your 5G-modem do any NAT on its own or does it just forward the DHCP to the ISP?

So in short https://vyos.dev/T5440 will be broken again?

It was fixed in a keepalived project.
https://github.com/acassen/keepalived/commit/9ca8688c7fe591e1face259f19ee6169e20a3438

Should be fixed in https://vyos.dev/T5232
needs to re-check

Does your 5G-modem do any NAT on its own or does it just forward the DHCP to the ISP?

Could also be if legacy spanning-tree is being used that it will take approx 25 seconds before packets are being forwarded after a linkdown - workaround here is to enable "spanning-tree portfast" or disable spanning-tree.