Wouldnt this break things with compatibility with other vendors?

I agree, even if its "odd" at first sight I like that all interfaces are named ethX within VyOS and then its a matter to map each to physical interface by hw-id (which is done automagically during first install but can be remapped if wanted).

Does all the interfaces at bananapi represent a hw-id which can be used to map to the ethX syntax of VyOS?

The fear of having the HTTP-API part of nginx compromised by another virtualhost config (as in they are sharing the same process) should be overcome by having a dedicated config file and start a 2nd nginx process.

I would vote for that (using nginx as backend since it already exists).

Instead of "file-server" I think "http-server" would be a better name or even "web-server" in this context.

Verified with VyOS 1.5-rolling-202311081451.

I would mainly want to log new conntrack entries for various reasons.

Do you have any example of in which context that exists?

In that PR, shouldnt also ifb* be included?

Shouldnt dummy* and some others be excluded aswell?

@shthead: Im talking about features in VyOS. I dont care what others such as Juniper does or doesnt do.

@shthead: Yes but when it comes to multihoming there are some additional settings that should exist aswell:

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

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

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

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 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 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"?

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

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

For the record.

To verify that it isnt something in your 5G modem that triggers this behaviour try to put a L2-switch in between and then simulate a link failure between VyOS and this L2-switch and see how things behaves?

Plenty of nat66 related errors from last nightly build:

Using VyOS 1.5-rolling-202310220123.

I think the commit made by yzguy is referencing the wrong task-id.

Should debug code really be part of production releases?

What if you install the same version again but as a new boot name?

Out of the blue it looks like some compile thats gone wrong?

What is the exact path within the chroot directory?

Still fails:

I think it should be included, its often used during generation in Debian among other distros.

Then this task can be set to closed and invalid :-)

PR updated: https://github.com/vyos/vyos-build/pull/435

But the NAT_CONNTRACK and WLB_CONNTRACK chains are never evaluted because FW_CONNTRACK always set action to accept?

I assume this will end up in config mode aswell before this task can be set to resolved?

The syntax seems to have changed from "produce" to "generate" during this task?

Updated scan performed on VyOS 1.5-rolling-202310090023 (see attached file).

show conntrack statistics still fails in VyOS 1.5-rolling-202310090023:

Seems to be fixed in VyOS 1.5-rolling-202310090023:

Problem remains with "N/D" is being used in show firewall groups instead of "None".

Verified in VyOS 1.5-rolling-202310090023:

Verified in VyOS 1.5-rolling-202310090023:

Works as expected:

PR created: https://github.com/vyos/vyos-build/pull/435

As @twan mentioned previously...

Turns out that packages/linux-kernel/arch/x86/configs/vyos_defconfig doesnt include xz as option for initrd:

Will attempt to:

A new firewall frontend engine was implemented in VyOS 1.4-rolling-202308040557.

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

The blog over at claims:

PR created: https://github.com/vyos/vyos-build/pull/434

Regarding STRIP_EXCLUDE variable... one idea is to assign it dynamically like so:

@xrobau noted that PR426 have an anomaly regarding one of the libraries during the strip-run:

Also adding these lines as to "completely ignore conntrack for all traffic" doesnt seem to help:

Merged, will show up in nightly 2023-10-04.

Merged, will show up in nightly 2023-10-04.

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

PR created (for current): https://github.com/vyos/vyos-build/pull/432

Please revert that commit (remove that hook) and use the excludes-file instead.

I suppose the maintainers already considered the below but I got a suggestion on how to resolve this issue:

Created https://vyos.dev/T5622 which must first be resolved before T5593 can get successfully merged.

PR updated for part 1/2 (vyatta-cfg-system): https://github.com/vyos/vyatta-cfg-system/pull/209

PR updated for part 2/2 (vyos-build): https://github.com/vyos/vyos-build/pull/427

PR created for part 1/2 (vyatta-cfg-system): https://github.com/vyos/vyatta-cfg-system/pull/209

Build was successful and smoketests are currently in progress.

If build and smoketests are successful a commit will arrive later today.

Point 1 might be solved by using a hooks/live-script for the binary part which is the part after the chroot have been created.