Is it possible to report an error or warning when on-demand dialing is enabled without negotiation between remote IP and local IP? If warned, an error fallback should be supported

I have no clue what you are talking about

I already know what the problem is, using dial on demand requires negotiation to be disabled (specify remote IP and local IP explicitly)?

Issue can not be reproduced:

@c-po Why stop the implementation of this function? My original idea was to implement the automatic configuration and operation of the service in vyos-1x. It seems that you already have an idea?

This only happens when there are multiple <path> options.

The issue did not reproduce in the VyOS 1.3-rolling-202007140117 version. Also commit fails if the local-ip is missing

Reproduced in VyOS 1.3-rolling-202007140117 version
When the mac address is added to the interface manually, the interface is marked down.

A PR #502 is created to fix the issue:
https://github.com/vyos/vyos-1x/pull/502

@c-po Please review my PR

I spoke too soon, I rebooted and nothing yet again until i ran

Resolved: It seems either my config or something else has changed but I figured it out just now after a coffee and some noodle scratching.

Just did a test that I havent before for unknown reasons

This is issue is reproduced in the VyOS 1.3-rolling-202007140117 version.
While changing the mode of the pseudo-ethernet interface, the error "RTNETLINK answers: Invalid argument" is received

https://github.com/vyos/vyos-1x/pull/499

@thomas-mangin please fix it

@SrividyaA the task is assigned to you, if you are going to fix it, all good, otherwise happy to do so.

Can I make a suggestion? Since this DDoS detection supports user script processing, it is better to migrate the script during the vyos upgrade to prevent script loss

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

Did the changes on dependencies file here: https://github.com/Maltahl/vyos-1x/commit/27400e09b27d98b6ee34568fe25828cff1d14770

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

Final tests before PR.

If someone could point me in the direction where wireguard config files are stored in VyOS i will be happy to test it out further.

I tested by just adding default debian buster repos and run

sudo apt install qrencode

This is issue is reproduced in the VyOS 1.3-rolling-202007140117 version. The interface description is showing up-to 23 characters in the "show interface output" only.
It shows correctly in the command output of 'sudo ip l" Tested for different interface types.

https://github.com/vyos/vyos-1x/pull/496

https://github.com/vyos/vyos-1x/blob/current/debian/control

Please prompt me the correct path to the vyos-1x dependency list @runar

I am about to make an amendment

Hi! This PR does the wrong approach for adding this command to the vyos system. As this is a utility that should be used from within the CLI it should be added to the cliwith the xml framework inside vyos-1x, and rhen should be a dependency of vyos-1x, and not to vyos-build

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

Current version linked below, as an example for further discussion. As these ideas have been circulating for a while, it is important to have examples to debunk/revise/reject. My guess is that one likely wants much less than this, and that @dmbaturin is quite right in his recent comment "we should not rely on diffs unless there's absolutely no other way to do it --- not just about computational expense, but also readability".

https://github.com/vyos/vyatta-cfg-vpn/pull/34

https://lwn.net/Articles/822744/

After local testing, we decided to submit pr

I have prepared a repair pudding, I use the solution of a, I am hesitating whether to mention PR, otherwise, it should be noted in the document that the writing of B should be ignored in the vyos configuration

I need someone to give me a good choice. I prefer standard writing. That is a

@c-po @jjakob I've found the root cause of the problem. When my domain is written in fully qualified format, there will be one more point in the generated Lua script. There are currently the following solutions to this problem:

No one's dealing with it?

Closed in favor of https://phabricator.vyos.net/T1101

@c-po Please forgive me that I didn't react until it told me that this is a patch. It has solved the problem. In this case, if it is confirmed that the patch is available, then it is not necessary to discuss the cause of the problem. What we need to do is to apply the patch and conduct relevant tests

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.

If so, you should make it clear that the diff is your own patch. If you are sure that the patch is available in the latest rolling image, you can consider submitting a PR yourself (please refer to the contributor's Guide) to seek consolidation

This is worked patches for me. I suggest including my corrections in the main code

I thought you were asking for help and trying to report a bug to the community for a fix, so you need more information to help identify the problem, rather than a diff who doesn't know where to find it