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://lwn.net/Articles/822744/

After local testing, we decided to submit pr

When users use the standard fully qualified domain name writing method, there will be an extra point after the actual domain name. In order to ensure that the standard writing method is supported, it should not be mandatory to add this point in Lua script

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

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 patch for me

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

You mean you've fixed the bug? If so, you can consider submitting pr

I don’t understand you, is it really impossible to see from the diff that stupid errors have been fixed here.

I have just quickly browsed the relevant code of this code base. Generally speaking, the code structure is very clear, which is not difficult to understand. The overall operation of this daemon is divided into the following three processes:

I have to say that I saw the diff of this code base for the first time, but in fact, as for my understanding of C troubleshooting, analyzing the log and execution process will become a necessary work (none of them). I can see that the operation process required by this code base may be relatively complex, so that it can be executed as a background daemons rather than a single place According to the description of the questioner, there is hardly any relevant information that can be extracted from the error process. It is suggested to provide the following information:

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

If the process is simple, you can consider py script. If you need to run uninterrupted in the background or have other complex tasks, it is a good way to continue to use C/C++

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

Will this issue be fixed in the next release? Just in doubt, I've used Sha instead of MD5.

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.

Thank you. I'm in a hurry to solve the problem. If I neglect, I can try to use Sha and reset it successfully. Do you not support MD5?

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

The configuration is as follows:

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

Now, I don't know how to pull the SNMP data again. The command is as follows:

Can't I dial on demand when I need to negotiate?

When I manually add the following commands to the following file:

Have the opportunity to study whether it is because of pppd configuration file error?

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

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

Dial on demand still doesn't work

If you think about it carefully, maybe for vyos, if you don't consider supporting SDN, then Linux bridge is a good choice.