| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Both PPPoE and WWAN interfaces are dialer interfaces handled by ppp, but use
different CLI nodes for the same functionality. PPPoE has "connect-on-demand"
to initiate an "on-demand" dialing and WWAN uses "ondemand" for this purpose.
Rename WWAN "ondemand" node to "connect-on-demand".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now that b40c52682a256 ("config: T2636: get_config_dict() returns a list on
multi node by default") is implemented the workarounds can be removed.
|
|
|
|
|
|
|
|
... this reduces CPU load.
|
|
... required for smoketest and ConfigParser
|
|
DHCPv6 client was not started as it used the old dict keys.
|
|
When rapid-commit is specified, dhcp6c will include a rapid-commit option in
solicit messages and wait for an immediate reply instead of advertisements.
|
|
Currently DHCPv6-PD requires an interface address configured to dhcpv6 on the
CLI. This is not required also sometimes there is either no dhcpv6 interface
addressing available (PPPoE) or wanted. This limitation was artificial due to
the old interface code.
Change the implementation to spawn the DHCPv6 client and request a prefix even
when there is no address request configured.
|
|
The current CLI did not support multiple prefix-delegations per interface. Some
ISPs only send one /64 to a client per prefix-delegation request, but they
allow the customer to request multiple prefixes.
The 'dhcpv6-options prefix-delegation' node has been renamed and converted to a
tag node named 'dhcpv6-options pd'. The tag node specifies a PD request (>=0).
In the past the user needed to know what prefix will be assigned and required
to calculate the sla-len by himself. The 'sla-len' node was dropped and is now
calculated in the background from the 'dhcpv6-options pd 0 length' node.
It is no longer mandatory to supply the 'sla-id' node, if sla-id is not
specified it is 'guessed' by counting upwards.
Example configuration:
----------------------
ethernet eth1 {
address dhcpv6
dhcpv6-options {
pd 0 {
length 56
interface eth2 {
address 1
}
}
}
}
This will request a /56 assignment from the ISP and will delegate a /64 network
to interface eth2. VyOS will use the interface address ::1 on the delegate
interface (eth2) as its local address.
|
|
|
|
|
|
|
|
|
|
|
|
* 't2564-lcd' of github.com:c-po/vyos-1x:
lcd: T2564: flatten CLI interface
system display: T2564: Added test model
system display: T2564: Dictionary code update
system display: T2564: Conf files to /run
system display: T2564: Changed "duration" to "time"
system display: T2564: py code cleanup
system display: T2564: Replace "config (enabled|disabled)" with "display disabled"
system display: T2564: Lowercase model names
system display: T2564 Extend VyOS to support appliance LCDs
|
|
* set system lcd device <device>
* set system lcd model <modeml>
Both device and model have completion helpers for supported interfaces and LCD
displays.
|
|
Commit 21bc98f1 ("ifconfig: dhcp: T2767: client must not start when
interface is disabled") dropped dhcp.py which is now directly handled by
interface.py. This change should also be reflected in the generated files.
|
|
t2564-lcd
* 'system-display' of https://github.com/fmertz/vyos-1x:
system display: T2564: Added test model
system display: T2564: Dictionary code update
system display: T2564: Conf files to /run
system display: T2564: Changed "duration" to "time"
system display: T2564: py code cleanup
system display: T2564: Replace "config (enabled|disabled)" with "display disabled"
system display: T2564: Lowercase model names
system display: T2564 Extend VyOS to support appliance LCDs
|
|
When running SSH from the VyOS system the source IP address can be set by:
set system options ssh-client source-address x.x.x.x
|
|
|
|
Move sshd_config file to /run so it must be generated on every boot and is
not stored accidently.
|
|
Pass the interface dictionary transparently to the DHCP module and render the
DHCP client config template directly from the same source instead of transcoding
it once more.
|
|
This removes additional code paths as we can instatly work with the input dict
the same was as it was done for PPPoE. This fixes the entire DHCPv6-PD support
on non PPPoE interfaces as this was lost in translation while processing T2653.
|
|
Make the port used for RADIUS accounting user configurable. This is now
valid for the following services which are based on Accel-PPP:
* ipoe-server
* pppoe-server
* l2tp
* pptp
* sstp
|
|
|
|
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
|
|
|
|
Add additional verify() stage to check that the relaying interface actually
exists on the system.
|
|
* '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
}
}
}
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
