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.

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

Turned out to be little of a challenge do "just" strip all binaries (and libraries, modules etc).

Have to add Debian package "binutils" to make "strip" work within the chroot of livebuild.

Implement hooks-script for livebuild that recursively go through following directories using "strip --strip-all" (syntax to be verified):

Shouldnt that be default for lb then in the vyos buildscripts and how does --debug affect things other than logging during build?

What is the "system update-check url" supposed to be once its implemented?

Verified to be working as expected.

@jestabro I havent verified it yet but then perhaps the buildscript for VyOS should be altered to include --verbose?

Verified through smoketests.

Verified through smoketests.

The quickfix is to add a space for your paths so something that looks like /usr/local/bin if cloudflare blocks that you just add a space after the first / and the WAF is bypassed.

Ehm, that hint already exists at line 2 of that file?

Oops, sorry about that!

In T5601#160566, @vvinci00 wrote:

Hello,

I need to reverse proxy TCP traffic.
the traffic is not HTTP/HTTPS

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

Some highly unscientific tests (only did 3 reboots of each to rule out that any uncached data at the host would affect the result since I run this in a VM through VirtualBox 7.0) shows a difference of up to 2.1% improvment when having a config with 200 static routes.

Perhaps a possible way to detect if the nic supports hardware flowtables or not.

Some feedback from the #netfilter channel over at libera.chat:

I got some funny results which I hope somebody else (with a faster cpu) are able to verify?

Im guessing that what this task complains about has a huge part of the time it takes to complete smoketests.

PR updated (again): https://github.com/vyos/vyos-1x/pull/2280

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

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

I will put this as "wontfix" because a fix would need additional work of stopping/starting correct FRR-service (if this occurs in future then this task can be reopened).