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:

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

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

After upgrading, the entire NAT section is gone

Error when upgrading to 1.3

Can confirm that the image now contains wireguard.ko.

Understood, will re-check and close the report once confirmed.

@linuxgemini we do not support DKMS.

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

@c-po When I manually add the following commands to the following file:

Did a rebuild and found the silent error:

While I was checking my old build, I have seen this on /live/filesystem.packages:

I need to modify the file(/etc/swanctl/swanctl.conf) manually, from emote_ts = dynamic[gre] to remote_ts = 0.0.0.0/0[gre].

I test that issue on 1.2.5. but not work

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?