And refuse a link-local address.
With the previous commit, now ServerAddress= can take a null address,
but the config parser refused that. Let's allow that now.
Previously, we periodically search suitable address for DHCP server,
1. when .network file is loaded,
2. when checking if we can configure sd_dhcp_server object,
3. when configuring sd_dhcp_server.
Especially, the step 2 may be triggered several times.
This makes, when .network file is loaded, find a corresponding Address
object, add a new Address object if not found, then save the found or
added Address object. So, it is not necessary to find address again on
configuring sd_dhcp_server object.
We need to find a suitable static address for the DHCP server.
So, all static addresses must be verified before network_adjust_dhcp_server()
is called. For safety, let's call it from network_drop_invalid_addresses().
No functional change, just refactoring and preparation for later
commits.
And drop sd_dhcp_client_get_lease_timestamp().
Also, this introduce sd_dhcp_lease_get_lifetime_timestamp() and friends,
which provides timestamp of the lifetime and so on, while
sd_dhcp_lease_get_lifetime() provides timestamp.
In file included from ../src/basic/macro.h:455,
from ../src/basic/alloc-util.h:10,
from ../src/basic/hash-funcs.h:4,
from ../src/basic/hashmap.h:8,
from ../src/shared/dns-domain.h:10,
from ../src/network/networkd-radv.c:9:
../src/network/networkd-radv.c: In function ‘config_parse_router_home_agent_lifetime’:
../src/network/networkd-radv.c:1626:28: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 11 has type ‘long long unsigned int’ [-Werror=format=]
1626 | "Invalid %s= must be in the range 1...%lu seconds, ignoring: %s", lvalue,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/basic/log.h:361:125: note: in definition of macro ‘log_syntax’
361 | ? log_syntax_internal(unit, _level, config_file, config_line, _e, PROJECT_FILE, __LINE__, __func__, __VA_ARGS__) \
| ^~~~~~~~~~~
../src/network/networkd-radv.c:1626:68: note: format string is defined here
1626 | "Invalid %s= must be in the range 1...%lu seconds, ignoring: %s", lvalue,
| ~~^
| |
| long unsigned int
| %llu
cc1: all warnings being treated as errors
Addresses: https://github.com/systemd/systemd/pull/28964#issuecomment-1705550404
Follow-up to 6a6d27bc5b.
No functional change. In config_parse_address_generation_type() we would set
the output parameter and then say it's ignored, so it _looked_ like an error in
the code, but the variable was always initialized to SD_ID128_NULL anyway, so
the code was actually fine.
This reverts commit 4ccd48cb26.
From RFC 4861 section 4.2.
> The Router Lifetime applies only to the router's usefulness as a default
> router; it does not apply to information contained in other message fields
> or options. Options that need time limits for their information include
> their own lifetime fields.
Hence, based on the lifetime field of the message header, we should not
drop any other information.
Note that, in ndisc_router_process_default(), we have already dropp the
default gateway when the lifetime is zero. Hence, we can safely drop the
change.
New directive `NFTSet=` provides a method for integrating network configuration
into firewall rules with NFT sets. The benefit of using this setting is that
static network configuration or dynamically obtained network addresses can be
used in firewall rules with the indirection of NFT set types. For example,
access could be granted for hosts in the local subnetwork only. Firewall rules
using IP address of an interface are also instantly updated when the network
configuration changes, for example via DHCP.
This option expects a whitespace separated list of NFT set definitions. Each
definition consists of a colon-separated tuple of source type (one of
"address", "prefix", or "ifindex"), NFT address family (one of "arp", "bridge",
"inet", "ip", "ip6", or "netdev"), table name and set name. The names of tables
and sets must conform to lexical restrictions of NFT table names. The type of
the element used in the NFT filter must match the type implied by the
directive ("address", "prefix" or "ifindex") and address type (IPv4 or IPv6)
as shown type implied by the directive ("address", "prefix" or "ifindex") and
address type (IPv4 or IPv6) must also match the set definition.
When an interface is configured with IP addresses, the addresses, subnetwork
masks or interface index will be appended to the NFT sets. The information will
be removed when the interface is deconfigured. systemd-networkd only inserts
elements to (or removes from) the sets, so the related NFT rules, tables and
sets must be prepared elsewhere in advance. Failures to manage the sets will be
ignored.
/etc/systemd/network/eth.network
```
[DHCPv4]
...
NFTSet=prefix:netdev:filter:eth_ipv4_prefix
```
Example NFT rules:
```
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
}
chain eth_ingress {
type filter hook ingress device "eth0" priority filter; policy drop;
ip saddr != @eth_ipv4_prefix drop
accept
}
}
```
```
$ sudo nft list set netdev filter eth_ipv4_prefix
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
elements = { 10.0.0.0/24 }
}
}
```
json_append() is a useful wrapper around json_variant_merge(). However,
I think the naming sould be cleaned up a bit of both functions.
I thinker "merge" is the better word than "append", since it does
decidedly more than just append: it replaces existing fields of the same
name, hence "merge" sounds more appropriate. This is as opposed to the
similar operations for arrays, where no such override logic is applied
and we really just append, hence those functions are called "append"
already.
To make clearer that "merge" is about objects, and "append" about
arrays, also include "object" in the name.
Also, include "json_variant" in the name, like we do for almost all
other functions in the JSON API that take a JSON object as primary
input, and hence are kinda object methods.
Finally, let's follow the logic that helpers that combine json_build()
with some other operation get suffixed with "b" like we already have in
some cases.
Hence:
json_variant_merge() → json_variant_merge_object()
json_append() → json_variant_merge_objectb()
This mirrors nicely the existing:
json_variant_append_array()
json_vairant_append_arrayb()
This also drops the variant of json_append() that takes a va_arg
parameter (i.e. json_appendv()). We have no user of that so far, and
given the nature as a helper function only I don#t see that happening,
and if it happens after all it's trivial to bring back.
This reverts commits 89e73ce86f and
543d2a4d45.
The commit assign "custom" to fixed DUID type 5. When making DUID fully
configurable, the type number should be also configurable. Also, the
fully custom DUID should be acceptable for DHCPv4.
Include T1 and T2 DHCPv6 options to expose in dbus API.
Introduced new field DHCPv6lease where these options are
added. This will be added to the JSON output when we query
org.freedesktop.network1.Manager object.
A Lifetime of 0 indicates that the router is not a default router anymore
and associated default route should be discarded from host's routing table.
https://datatracker.ietf.org/doc/html/rfc4861
```
Router Lifetime
16-bit unsigned integer. The lifetime associated
with the default router in units of seconds. The
field can contain values up to 65535 and receivers
should handle any value, while the sending rules in
Section 6 limit the lifetime to 9000 seconds. A
Lifetime of 0 indicates that the router is not a
default router and SHOULD NOT appear on the default
router list. The Router Lifetime applies only to
the router's usefulness as a default router; it
does not apply to information contained in other
message fields or options. Options that need time
limits for their information include their own
lifetime fields.
```
Lennart Poettering
Yu Watanabe
Mike Yuan
Luca Boccassi
Frantisek Sumsal
Susant Sahani
pelaufer
Zbigniew Jędrzejewski-Szmek
Topi Miettinen
Nandakumar Raghavan