UpNP was removed

Problem was not reproduced

This appears to be a kernel issue.

I think we hit the same issue in 1.4.3. This is reproducible with the following configs:

Tested NTP, setup-delete-setup
First Setup :

Сhecked test all combination :

Have test on VyOS 2025.09.01-0023-rolling

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

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

The VyOS 1.3.x is EOL
for the newest versions fix here https://github.com/vyos/vyos-1x/pull/4663

In this case, can we have a proper error message for unsupported hw?
Also it seems strange that x710 supports VPP/DPDK but lacks TC_SETUP_FT.

@kakurpiel is correct, TC flowtable does not work with Intel cards due to lack of driver support. I suggest this ticket can be closed.

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

the ticket is closed, and

ssh vyos@vyos -- /opt/vyatta/bin/vyatta-op-cmd-wrapper show interfaces

I'm getting this same (or very similar) issue on 1.4.2LTS (running on VEP-4600).

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

PR 4609 submitted to adjust MSS clamping from forward hook to postrouting.

Looking at this again, and it seems like if the nft rule is moved from forward hook to postrouting hook that MSS is adjusted appropriately.

Fix of commit-config after changes: https://github.com/vyos/vyatta-cfg/pull/107

https://github.com/vyos/vyatta-cfg/pull/103

Could be closed

vyos@r14# grep speed /opt/vyatta/etc/config/config.boot
            speed "115200"
[edit]
vyos@r14#

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

I have created a merge request: https://github.com/vyos/vyos-1x/pull/4508

@Viacheslav,
default must have the same ipv4 subnet of "podman" default network, if changed, Podman doesn't detect it (via conf-mode commands).

@covalente, should we disable the name default? Or do you have another idea?

After further debugging, it's the network name that causes the issue with CNI creation (pod-*) and static ip.
Podman overlaps "podman" default network and the user-defined "default" network.
containers get assigned to "podman" default network and CNIs ignored, so causing this primary issue.

@covalente Add a simple set of commands to reproduce, thanks!

@fernando Could you please re-test in the latest rolling release image?

I've issued a PR for this at https://github.com/vyos/vyos-1x/pull/4482, attempting to address a few things T5816 missed.

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

In T6253#190207, @giuavo wrote:

Are you sure your DHCP server honors the no-default-route option?
I may be wrong, but I think the no-default-route just sets an option in the DHCP request, asking the DHCP server to not send back the default route.
I have the same issue with my ISP, and they told me they will always send a default route via DHCP.
I have solved the issue using DHCP hooks.

Any updates on this? I am also affected.

Tested as working in: VyOS 2025.04.19-0018-rolling

If you have a device that beeps, could you check if this changes anything?

beep-if-fully-booted was renamed to startup-beep in T3078 / 193323b.

Please can this be considered for VyOS 1.5?

@trae32566 It is not reproduced in the test lab.
Are you still having issues with it?

There was no a change - I tested with the existing code in trunk and could not replicate the issue - hence the question, given this is a pretty old bug report

@Apachez I believe @evgmol was referring to:

In VMware vSphere, in multiple devices these log messages are seen after upgrading to 1.4.1 version:

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

I am implementing this feature now!

In T6821#217838, @evgmol wrote:

Are we happy with the above patch (fixing the terminal)?

Hi,
I tested with 520-700+ character long strings and the bug is not evident in 1.3- or1.4+ versions
Can you please re-rest and advise this issue still persist

Are we happy with the above patch (fixing the terminal)?