- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 15 2020
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
Jul 14 2020
@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".
Jul 13 2020
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
No one's dealing with it?
Closed in favor of https://phabricator.vyos.net/T1101
Jul 12 2020
@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
@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:
Jul 11 2020
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
Jul 10 2020
Have the opportunity to study whether it is because of pppd configuration file error?
pppoe pppoe0 {
authentication {
password pass
user user
}
+ connect-on-demand
default-route force
description ISP
dhcpv6-options {
prefix-delegation {
interface br1 {
address 101
sla-id 2
sla-len 8
}
interface br2 {
address 101
sla-id 1
sla-len 8
}
length 56
}
}
firewall {
in {
ipv6-name WAN-IN
name wan
}
local {
ipv6-name WAN-LOCAL
name wan-local
}
}
idle-timeout 30
ipv6 {
address {
autoconf
}
enable
}
mtu 1492
source-interface eth5
}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.
Jul 9 2020
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.