https://github.com/vyos/vyatta-wanloadbalance/commit/ab841d3588c88e0e8ef86693471281badce92a9f

@jack9603301 the approach from @banditos13 is perfectly fine. Despite the fact that a PR would be the non plus ultra - a problem was identified and a fix was provided - works for me.

Are you familiar with that codebase @jack9603301? As I see no real answer in your posting which does not help at all :(

I feel more like abandoning that daemon and use a python based implementation.

New ISO build triggered with fix - also an MD5 smoketest was added

Bug in the library is confirmed - id completely ignores MD5

Problem seems to be in the 3rd party hash library - when upgrading from 1.2.5 to 1.3 rolling settings persist and work:

MD5 should be supported as it works in VyOS 1.2 - let me have a look.

It is stated in the documentation - that is why I passed it to you

The following rules are now installed after the fix:

Your above ruleset should be tralnsated into thie NFT syntax:

There i no community in SNMPv3 - please read https://docs.vyos.io/en/latest/services/snmp.html#snmpv3

@linuxgemini we do not support DKMS.

Well a bit more verbosity would be good. As usual:

• provide config
• logfiles
• routing table
• interface ip list

There is a basic test for this which should be expanded.

A very fast look on the source indicated wrong dictionary kissed missed out during migration to get_config_dict() - please try next rolling.

My guess is this will be resolved by the full BGP rewrite - I also do not like the current behavior.

Using the mentioned defaults in https://tools.ietf.org/html/rfc3414#appendix-A.3.2

This somehow relates to T2651

The reason this is failing is VyOS 1.2 lacks proper input validation on the loglevel nodes.

So should be cherry-pick this to 1.2.6?

Just digging around I found this:

There is already a new build containing the fix.

@Viacheslav could you please check if this probably should make it into 1.2.6 in addition?

https://github.com/vyos/vyatta-cfg-quagga/pull/51

Problem was introduced by porting PPPoE to the get_config_dict() implementation T2653 commit https://github.com/vyos/vyos-1x/commit/65fa21f5

Does DNS static-host-mapping still work with the nssswich.conf change? I‘m just curious about the side effects.

Somehow I do not want to change the overall system behavior by altering nsswitch.conf. I wonder if we should not enable "disable-host-ookups" by default as an IP address is in the end more useful then a resolved PTR. A PRT can be changed later on when dissecting the logfiles but an IP lookup should stay longer.

Linux tries to bind SSHd to the VRF but it is yet not ready. After restarting SSH to often (rate-limiting) it is blocked.

Changing the systemd defaults is a thing I hesitate to do! It will have a ton of unexpected sideeffects. I guess you have an error in your entire setup as multiple sites of mine work flawlessly

I found that I had disable-host-validation configured and as soon as I removed it it happened to me, too. Changing task priority.

I have checked with a v4/v6 full table router and VyOS 1.2.5 - each SSH session will consume 7MiB which semms okay for me.

Availible in keepalived, thus kt could be considered for 1.3

Again, please always attach a configuration file

I use myself a "cleanup" function, imagine:

In T2674#69525, @jack9603301 wrote:

I wish you success in advance. Porting and compiling has always been a large-scale application project, which may take a lot of time. However, in addition to rewriting and porting related code to a more portable language, we can also try to transplant and cross build the existing old code first. Of course, this is only the first step. If possible, porting the code base has made it easier for the code base to be transplanted Meaningful.

As "ip" is an invalid key in "vif" (as its no VLAN number) it should not be part of the default dict I guess - same for vif_s

porting half of an operating system to a different architecture is far from easy. Right now VyOS still has a lot of the old Vyatta codebase in it. As we are more and more in the process of migrating this to a Python based codebase it will still take some time. To be fair I stater a project some time back to port VyOS on an EdgeROuterPro (https://github.com/c-po/vy-project) and at least "it booted" but I then switched my focus to VyOS first - so by migrating th ecodebase to our own vyos-1x based Python implementation it will become easier in the future to port it to other operating systems as there is less code, less packages to port.

As always, please provide your config and probably a way to reproducs.

The login banner was always user configurable, see https://docs.vyos.io/en/latest/system/user-management.html?highlight=banner#login-banner

@elbandi could you please submit a PR?