PR for global solution extends the local solution in T5839:
https://github.com/vyos/vyos-1x/pull/2659

PR
https://github.com/vyos/vyos-1x/pull/2659
updated and extended for T5660.

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

This was resolved by merged PR. Build process now succeeds.

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

We should keep this behavior in 1.3.7 but change it for 1.4 and onwards

Not a regression as far as this task is concerned. Will update T6073

Full configuration:

Reopened on @Apachez request

Provide please show configuration commands or attach /config/config.boot file.

How do one re-open? :-)

Similar task(s):

Yes, this is only used by the GraphQL API.

While at it having a description for a firewall rule within the firewall itself thats longer than 256 is just "wrong" IMHO aka "you are doing it wrong".

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

@tjjh89017 Have a look at https://vyos.dev/T5965

In T5619#177706, @ErnyTech wrote:

Unfortunately I haven't seen this before, for me this choice of using the out-of-tree driver is extremely wrong!

Most of the community's development is done on the mainline kernel driver (where among other things I'm working on sending patches to improve the ixgbe driver), if there are issues in the mainline driver they should be reported or resolved with a patch to be applied in vyos downstream and then send it to the Intel-wired-lan mailing list.

Please @samip537 can you tell me in a short list what exactly problems you encounter with the mainline Linux driver?

On 1.4.0-epa1, there is no longer an indication that configuration file actually has been saved.

1.4 and 1.5 run on strongswan 5.9.11

@c-po I suggest that we should reopen this issue. And I have a question is why DHCP server with VRF support works correctly in v1.4 but not in v1.5？

I'm using a workaround. I'm running a process in a script /config/scripts/vyos-postconfig-bootup.script:

In T4733#148990, @c-po wrote:

Hi @daniil and @NikolayP,

this is already implemented and working. You need to specify: set vrf bind-to-all and it will work out of the box with your configuration stated above

I have created a PR to resolve this issue: https://github.com/vyos/vyos-build/pull/511

In T4733#148990, @c-po wrote:

Hi @daniil and @NikolayP,

this is already implemented and working. You need to specify: set vrf bind-to-all and it will work out of the box with your configuration stated above

Adding https://forum.vyos.io/t/quick-and-dirty-benchmark-of-cores-vs-mhz/13831/ for reference which also concludes that something is off with the commit and boot times of VyOS.

I can verify @samip537's comments -- the X553 interface won't establish link state using the default ixgbe driver included in Linux kernel 6.1 or 6.6. In my case, I'm testing hardware with X553 interfaces against a Dell PowerConnect 8132F. Qualified/Non-Qualified modules or DAC-cables make no difference. Using the OOT Intel driver, however, does work as one would expect.

recently mentioned on netdev (upstream bugs and other threads linked as well):

The issue is raised in this forum query: https://forum.vyos.io/t/commit-archive-doesnt-accept-symbols-in-password/13817
Remote host having password with special character is not accepted using with scp command

@ErnyTech This has been discussed at the forums in length what the problems are, but most of them seem to come from an link-related commit in the in-tree driver: https://marc.info/?l=linux-netdev&m=170113799914642. Meaning that no matter what one does, with the built-in driver, one cannot establish a link between X533 and eg. Juniper switch but they do see each other according to transceiver information but just no link.

Unfortunately I haven't seen this before, for me this choice of using the out-of-tree driver is extremely wrong!

It's a good news for me. I will shift from SRX320 to Vyos system. In FTP active mode, the FTP server will push the data channel to the client, the Vyos deems it as a new connection and there is no need with FTP ALG.

In T5376#177587, @sarthurdev wrote:

@svd135 can you try on latest rolling?

Perfect, would it be possible to update https://docs.vyos.io/en/sagitta/changelog/1.4.html and doc pages like https://docs.vyos.io/en/sagitta/configuration/firewall/groups.html accordingly ?

@svd135 can you try on latest rolling?

In T970#177585, @olivier.hault wrote:

I'm not sure if this was been included in version 1.4 or not?

I'm not sure if this has been included in version 1.4 or not?

In T970#177580, @olivier.hault wrote:

Any updates ?

Any updates ?

I'll get a new build going and give this another test.

Should be fixed by https://github.com/vyos/vyos-cloud-init/commit/fd8c12784127e3258762d0163455d595b427ea53

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

After normalization of PR (compare with examples from T5939)

hi, this is an example of the accel-pp.conf section for PPPoE, using the documentation as reference.

[pppoe]
pado-delay=100

@lclements0 Can you re-check?
Probably was fixed in https://github.com/vyos/vyos-cloud-init/commit/412287741b70b536458d84972257eda0b3c18d9f