| Age | Commit message (Collapse) | Author |
|---|
|
interface: T2519: add broadcast address when adding IPv4 addresses
|
|
This adds the last IP of the subnet being added as the broadcast address.
Example: adding 192.0.2.1/24 would yield:
inet 192.0.2.1/24 brd 192.0.2.255 scope global dum0
Without this the broadcast address would be missing.
Addidionally join two is_ipv4 calls into one.
|
|
Improve readability of the port validation. Also fixes T2708.
|
|
Add additional verify() stage to check that the relaying interface actually
exists on the system.
|
|
Commit 3435b251 ("monitor: ndp: T2706: remove ability to send commands") flipped
the filename and placed the tree in front of the subtree. Unfurtunately I mixed
up NTP and NDP. This has been corrected.
|
|
configdiff: T2689: add configdiff class
|
|
The configdiff class provides:
(1) An abstract representation of VyOS config state, for use in
configuration mode scripts.
(2) Methods to query the differences between the effective and session
config.
|
|
The "monitor" operational mode tree is for listening in on logfiles, chatter
on the wire or other things - it subscribes to the system. Hence it should under
no circumstances - ever - generate data. Sending our those requests, same as
e.g. calling ndisc6 should be placed under a different node.
Which one? I yet have no idea.
|
|
interface
Changes are made in the interface.py script in order to bring the admin state to 'UP' after the mac is manually added in system config.The script is marking the interface from up to down state(as the MAC address can only be changed if interface is in 'down' state) but it is not bringing it up after the change
|
|
|
|
|
|
ndptool: T2706: Support NDP protocol monitoring
|
|
It supports NDP protocol monitoring.
The submission supports the following features:
- Support the monitoring of specified port or all ports
- Supports monitoring of specific message types
- Support sending specific NDP message
|
|
This is a minor modification of the implementation by Thomas Mangin.
|
|
pseudo-ethernet: T2626: Fix for changing interface mode
|
|
Since it is not impossible to change MACVLAN interface mode on the fly, this fix adds a new one trigger to recreate it from scratch if the mode changed in system config
|
|
|
|
|
|
flow-accounting: T2695: Fixed crash on viewing flows with incomplete data
|
|
If flow records contain entries with skipped details, this does not allow preparing it for the output table. This fix use safe .get() function to return empty values instead crashing.
Also, added several small formatting fixes.
|
|
* 'curlrc' of github.com:c-po/vyos-1x:
http-client: T2651: support specifying source-interface/address for curl
xml: T2651: provide general source-interface include file
|
|
Please note that either interface or address can be configured.
system {
options {
http-client {
source-interface eth0
source-address 1.1.1.1
}
}
}
|
|
|
|
dns: T2675: fix recursor.vyos-hostsd.conf.lua
|
|
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
|
|
The 3rd party library used for calculating the SNMP hashes in advance only
worked for SHA and nod for MD5 as SHA was hardcoded [1]. The code has been
replaced by a class-less implementation providing only the required
functionality.
[1]: https://github.com/TheMysteriousX/SNMPv3-Hash-Generator/issues/2
|
|
|
|
|
|
|
|
As of now when adding new credentials for any SNMPv3 user we submit the
credential either plaintext or encrypted. A plaintext credential will be hashed
by SNMPd in the background and then passed back into the CLI so it's not stored
in cleartext. This feels like the wrong way in changing the CLI content with
data produced by a 3rd party daemon which implements the service.
It feels like the tail wiggles the entire dog.
This should be changed in the following way:
- After retrieving the plaintext password from CLI, use Python to hash the key
in advance
- Re-populate the encrypted key into the CLI and drop the plaintext one
- Generate service configuration and continue startup of SNMPd
This also fixes a race condition when SNMPd started up but not properly
provided the hasehd keys in the configuration resulting in a ConfigurationError.
Now as we also support binding SNMPd to a VRF this fixes a deadlock situation
on bootup as we can only bind late to the VRF and require up to 5 restarts of
the service - but the service will never start.
|
|
Match the full input string in regex validation. Previosly "sha123456" was
allowed by the validator but we only support "sha".
|
|
|
|
Commit 65fa21f5e ("ifconfig: T2653: move pppoe interface to get_config_dict()")
directly takes the configuration keys from the CLI config and thus the keys
used for template generation have not been updated appropriately.
|
|
pppoe: ipv6: T2693: Fix a bug in dhcp6c for PPPoE
|
|
Commit 03fb97 (pppoe: ipv6: T2681: script bugfix after get_config_dict() migration )
After the PPPoE link is reset, dhcp6c cannot be restarted,
which may cause the prefix delegation of IPv6 to fail to restart.
This submission will restart dhcp6c after the IPv6 of PPPoE is up again
|
|
When migrating the conf from VyOS 1.2 to 1.3 a configuration error could appear
if the user specified "info" as loglevel instead of "INFO". There was no input
validation done in 1.2 but this is now enforced in 1.3.
In VyOS 1.3 loglevel will be always lowercase on the CLI and when migrating the
config this is transformed. Also VyOS 1.2 accpeted any arbitrary loglevel. If
an invalid loglevel is found it will be set to info.
|
|
xml: T2582: rename xml tags
|
|
The current use of () does not allow to use found()
Converting to [] like all other tags
|
|
Commit 65fa21f5 ("ifconfig: T2653: move pppoe interface to get_config_dict()")
did not rename the Jinja2 template vars as required as they are not retrieved
directly as dict from the config backend.
|
|
ids: T2659: Add priority after bgp for correct service starting
|
|
|
|
Linux tries to bind sshd to the VRF but it is yet not ready - for any arbitrary
reason. After restarting SSH to often (rate-limiting) it is blocked by systemd.
Using Restart/RestartSec is not enough - systemd services use start rate
limiting (enabled by default). If service is started more than StartLimitBurst
times in StartLimitIntervalSec seconds is it not permitted to start any more.
Parameters are inherited from DefaultStartLimitIntervalSec (default 10s) and
DefaultStartLimitBurst (default 5).
|
|
Linux tries to bind sshd to the VRF but it is yet not ready - for any arbitrary
reason. After restarting SSH to often (rate-limiting) it is blocked by systemd.
Using Restart/RestartSec is not enough - systemd services use start rate
limiting (enabled by default). If service is started more than StartLimitBurst
times in StartLimitIntervalSec seconds is it not permitted to start any more.
Parameters are inherited from DefaultStartLimitIntervalSec (default 10s) and
DefaultStartLimitBurst (default 5).
|
|
Linux tries to bind sshd to the VRF but it is yet not ready - for any arbitrary
reason. After restarting SSH to often (rate-limiting) it is blocked by systemd.
Using Restart/RestartSec is not enough - systemd services use start rate
limiting (enabled by default). If service is started more than StartLimitBurst
times in StartLimitIntervalSec seconds is it not permitted to start any more.
Parameters are inherited from DefaultStartLimitIntervalSec (default 10s) and
DefaultStartLimitBurst (default 5).
|
|
VRFs should be created as early as possible.
|
|
|
|
|
|
ids: T2659: Add get_first_key to get_config_dict
|
|
|
|
ids: T2659: Implement fastnetmon support
|
