| Age | Commit message (Collapse) | Author |
|---|
|
In certain split DNS configurations, there is a need for more
fine-grained control over the local address DNS forwarding uses to
issue queries. The current pdns_recursor configuration allows the
recursor to send queries from any available address on the interface
the OS selects for the query, with no option to limit queries to a
particular address or set of addresses.
This commit exposes the `query-local-address` option in
`recursor.conf` to users via the `service` `dns` `forwarding`
`source-address` config node.
If the parameter is unspecified, the default value of 0.0.0.0 (any
IPv4 address) and :: (any IPv6 address) are used to match current
behavior.
Users who want more control can specify one or more IPv4 and IPv6
addresses to issue queries from. Per pdns_recursor docs, the recursor
will load balance queries between any available addresses in the
pools. Since IPv4 and IPv6 are different pools, note that specifying
only one type of address will disable issuing queries for the other
address family.
|
|
dhcpv6: T2961: support stateless dhcpv6 clients
|
|
For both source and destination NAT always the LOG name contained DST - which
is definately false. This has been corrected to use SRC and DST on the
appropriate rules.
|
|
This commit adds support for configuring the DHCPv6 server to serve
"stateless" DHCPv6 clients (those that send an information-request
message and do not request an address).
The change introduces a `common-options` node at the
`shared-network-name` level, which allows specifying options
applicable to clients regardless of subnet assigned (or in the case of
stateless clients, when no subnet is assigned). Parameters specified
at the subnet level take precedence over those set at the
shared-network level.
Presently, only parameters that are meaningful to stateless clients
have been exposed under `common-options`, as there is no precedent of
exposing parameters at multiple levels under the current DHCPv4 or
DHCPv6 configuration syntax. If desired, additional parameters could
certainly be added with relative ease.
|
|
|
|
|
|
Required to get a common CLI for all services provided by Accel-PPP. Once the
CLI for each service is consitent - Jinja2 templates can be reused together
with get_config_dict().
|
|
|
|
|
|
ntp: T2944: By default do not listen port 123 on any address
|
|
For easier configuration read in (CLI) validation and also template rendering
it makes sense to drop the old, single implementation and move to the new,
generic get_config_dict() approach.
Recurring configuration parts like ip-pool, ipv6-pool and nameservers have
also been split our into individual templates which will be included through
Jinja2 - leading to a single-source of the template sections, too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
