@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://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

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 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?

@c-po 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.

I have been thinking about a problem. OVS can work in SDN controller mode. However, if OVS works in SDN controller mode, whether router related functions related to routing configuration will fail. If someone wants to implement it, then whether SDN switching control mode and non SDN related modules need exclusive processing to prevent conflicts should be considered.

After some benchmarking of this code i have i've gotten hold of a quite large test configuration that takes a waste amount of time to load into vyos.

Waiting for the next rolling version, thank you.

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

Can regression testing of some sort be added for this? I've seen this issue crop up before now, so I would guess this is a good candidate for that if possible.

@thomas-mangin I'm convinced: for get_child_nodes and get_node, we'll return a dict of respective dicts:

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.

Closed - this is available as set system ip layer4-hashing

Oh, neat. Thanks, I'll close this then!

I would very much like you reconsider classifying this as a bug if not security issue.

Is this bug report not handled?

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

The same for ipv6 is available under set system ipv6 layer4-hashing

HI! On 1.3 layer4-hashing is activated by using the set system ip layer4-hashing command

Okay, I like that video already ...

@thomas-mangin Firstly, I needed to write this version before reasonably debating the pros/cons of various approaches --- the important idea developed is that the use of get_sub_dict, and ability to return the sub_dict under the diff'ed nodes will allow a fluid use in writing conf_mode scripts --- beyond that, I am not particularly attached to any details of implementation, yet.

As I click "sail", I just realise that as there is only one config per router, ConfigDict could be a subclass of Config which could be itself singleton. So even if it is subclassed, all instances could/would share the same underlying data and could be used inter-exchangeably for the content of the config.

@jestabro I would like to hear why you advocate this API and why you believe it is better than the one I have suggested.

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

@thomas-mangin and @runar I do like the enum idea, however, this would add boilerplate to the conf_mode scripts, which would quickly become annoying in practice ... rather, common workflow just wants the actionable data (added, deleted) _and_ the ability to then access values under the node in question. Consequently, I'm following @runar 's suggestion of returning a tuple, combined with the return_as_dict arg to allow access to sub-data.