Resolved via T2653

Yes, I have migrated this a long time ago

A workaround is in place for this

Well I think its not necessary to change this back - we rather should extend the smoketests to detect those errors!

I will check next couple of days

Oh - I'm sorry - I mixed up the lines in the kernel. The patch is actually in VyOS.

@fetzerms the mentioned patch is not included in the mainline kernel!

@hammerstud that would work for you - but it will break everyone elses implementation ;)

It will break everything when in use ;)

Must be fixed after T2653 - then there is only a single truth for all interfaces

Option set! Kernel rebuilding

We have a ping CLI implementation

As VyOS is a hobby project for me and I‘m not paid by any party tvere is no progress planned in the near future from my side until ither things have been resolved. As you need it a contribution from your side would be much appreciated - all binary tools are in place.

Its always a good idea to research how other vendors are doong it - e.g. Arista, Cisco, Juniper and see if there is. common CLI ground.

Okay, and the reason you have not indicated your VyOS reason is because of?

Your log is not very helpful - a full log would be much better, that'
s why we have those show interfaces .... log commands

Then I guess you have not tested the latest version. Closing as Invalid.

I still don't get it - about which address you are talking about? 10.64.64.64 is pppd "hisaddr" which is 0x0a404040 + ppp unit number.

I have no clue what you are talking about

Issue can not be reproduced:

this implementation would ba an operational mode command. THose are deinfed here: https://github.com/vyos/vyos-1x/blob/current/op-mode-definitions/wireguard.xml and package dependencies life here https://github.com/vyos/vyos-1x/blob/current/debian/control

@moepman can you please try if the change introduced in T2651 is already sufficient for your usecase?

Implemented as of T2651

@dmbaturin was there anything changed on the handling of op-mode? As I remember that this used to work.

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 keys which have bewn 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.