For it's silly and unnecessary. Although it was apparently mandated by RFC 2462 in [5.5.2. Absence of Router Advertisements], that has been changed in the same section of RFC 4862, which obsoleted the former RFC.
dhcp6_request_address() was merely a function to switch the DHCPv6 client from "stateless" mode to "stateful" mode. It was also a one-way switch. Also, to (re)start the client, we would need to repeat separate function calls.
In this patch, dhcp6_request_address() is made a general starter/manager of the DHCPv6 client. It now takes an extra parameter so we will be specifying which mode the DHCPv6 client should be started in. Also it will keep track of the current mode and compare with the newly requested mode, and only restart the client in case there is a difference between them.
This also makes sure that the DHCPv6 client will be (re)started accordingly as per the Router Advertisement flags.
A field "index" is not particularly precise and also might conflict with libc's
index() function definition. Also, pretty much everywhere else we call this
concept "ifindex", including in networkd, the primary user of these libraries.
Hence, let's fix this up and call this "ifindex" everywhere here too.
DHCPv6 requires an IPv6 link-local address to work. The client will not be started (even when enabled explicitly with `DHCP=`) if none is configured (either by autoconfiguration or manually). Therefore, disable IPv6 in such case.
Although networkd has option (LinkLocalAddressing=) to toggle IPv6LL autoconfiguration, when it is enabled, the address is autoconfigured by the kernel, but not networkd.
Therefore, we do not statically set IFLA_INET6_ADDR_GEN_MODE to IN6_ADDR_GEN_MODE_EUI64, but dynamically depending on whether stable_secret is set, just as what the kernel does by default.
Note that this does NOT affect the global addresses configured by networkd.
Fixup for #3304.
Only warn, and not return, because that's what sd_dhcp6_client_start()
does right below the call to sd_dhcp6_client_set_local_address().
Starting the DHCP client doesn't seem like dhcp6_request_address()'s responsibility anyway. Whenever it's called, sd_dhcp6_client_start() is unconditionally called outside of it as well. See ndisc_router_handler() and ndisc_handler() in networkd-ndisc.c.
Now we are not dropping the IPv6LL address when link is down.
So next time when link is up and before kernel acquired this address
we are using the old address.
When the link is down kernel tells us that this address is no longer
valid . Let's remove this address and again when kernel tells us
that the address is added let's use it.
fixes#3264
This is partial fix for #2228 and #2977, #3204.
bridge-test: netdev ready
docker0: Gained IPv6LL
wlan0: Gained IPv6LL
eth0: Gained IPv6LL
Enumeration completed
bridge-test: netdev exists, using existing without changing its
parameters
vboxnet0: IPv6 enabled for interface: Success
lo: Configured
docker0: Could not drop address: No such process
vboxnet0: Gained carrier
wlan0: Could not drop address: No such process
eth0: Could not drop address: No such process
eth0: Could not drop address: No such process
eth0: Could not drop address: No such process
vboxnet0: Gained IPv6LL
vboxnet0: Could not set NDisc route or address: Invalid argument
vboxnet0: Failed
[New Thread 0x7ffff6505700 (LWP 1111)]
[Thread 0x7ffff6505700 (LWP 1111) exited]
Assertion 'link->state == LINK_STATE_SETTING_ROUTES' failed at
src/network/networkd-link.c:672, function link_enter_configured().
Aborting.
Program received signal SIGABRT, Aborted.
0x00007ffff6dc6a98 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
iptables-1.4.21-15.fc23.x86_64 libattr-2.4.47-14.fc23.x86_64
libidn-1.32-1.fc23.x86_64 pcre-8.38-7.fc23.x86_64
Debugging
(gdb) bt
"link->state == LINK_STATE_SETTING_ROUTES", file=0x5555556a34c8
"src/network/networkd-link.c", line=672,
func=0x5555556a56d0 <__PRETTY_FUNCTION__.14850>
"link_enter_configured") at src/basic/log.c:788
src/network/networkd-link.c:672
src/network/networkd-link.c:720
flags=0 '\000', scope=0 '\000', cinfo=0x7fffffffe020) at
src/network/networkd-address.c:344
(rtnl=0x5555556eded0, message=0x55555570ff20, userdata=0x5555556ec590)
at src/network/networkd-manager.c:604
m=0x55555570ff20) at src/libsystemd/sd-netlink/sd-netlink.c:365
at src/libsystemd/sd-netlink/sd-netlink.c:395
ret=0x0) at src/libsystemd/sd-netlink/sd-netlink.c:429
revents=1, userdata=0x5555556eded0) at
src/libsystemd/sd-netlink/sd-netlink.c:723
src/libsystemd/sd-event/sd-event.c:2268
src/libsystemd/sd-event/sd-event.c:2629
timeout=18446744073709551615) at src/libsystemd/sd-event/sd-event.c:2688
bus=0x5555556eeba0, name=0x55555568a2f5 "org.freedesktop.network1",
timeout=30000000,
check_idle=0x55555556adb6 <manager_check_idle>,
userdata=0x5555556ec590) at src/shared/bus-util.c:134
src/network/networkd-manager.c:1130
src/network/networkd.c:127
(gdb) f 3
src/network/networkd-link.c:672
672 assert(link->state == LINK_STATE_SETTING_ROUTES);
(gdb) p link->state
$1 = LINK_STATE_FAILED
We should not be in this state .
even if vboxnet0 failed we went into this state.
vboxnet0: Could not set NDisc route or address: Invalid argument
vboxnet0: Failed
Add an option to disable appending DHCP option 3 (Router) to the DHCP
OFFER and ACK packets.
This commit adds the boolean option EmitRouter= for the [DHCPServer]
section in .network files.
Rationale: On embedded devices, it is very useful to have a DHCP server
running on an USB OTG ethernet gadget interface to avoid manual setup on
the client PCs, but it should only serve IP addresses, no route(r)s.
Otherwise, Windows clients experience network connectivity issues, due
to them using the address set in DHCP option 3 as default gateway.
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
networkd currently silently accepts some strings as MAC addresses that it
probably shouldn't (like "ab💿ef:12:34:56:78" and "ab💿ef:12:3 4:56").
Add tests to MAC address parsing to ensure that we only accept valid MAC
addresses, and that we accept the three most common forms of MAC address
(colon-delimited hex, IEEE, and Cisco)
Several of these tests currently fail, but another commit in this series will
resolve them.
While creating a VLAN the mac address should be copied from the parent interface, so that
the VLANs inherit the MAC address of the physical interface.
Before:
```
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:26:c6:85:a3:c2 brd ff:ff:ff:ff:ff:ff
...
6: vlan1@wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 22:07:73:9d:43:59 brd ff:ff:ff:ff:ff:ff
7: vlan2@wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 46:30:76:33:35:d4 brd ff:ff:ff:ff:ff:ff
```
After:
```
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:26:c6:85:a3:c2 brd ff:ff:ff:ff:ff:ff
...
11: vlan1@wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:26:c6:85:a3:c2 brd ff:ff:ff:ff:ff:ff
12: vlan2@wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:26:c6:85:a3:c2 brd ff:ff:ff:ff:ff:ff
```
v2 of #1573, with fixed commit message.
This patch implements support for the IFLA_BR_MCAST_SNOOPING attribute
it can change the multicast snooping value.
IGMP snooping monitors the Internet Group Management Protocol (IGMP)
traffic between hosts and multicast routers.
It is just an alias for route_free which requires that route is not null,
but it was only used in one place where it was checked that route is not
null anyway. Let's just call route_free instead.
That function doesn't draw anything on it's own, just returns a string, which
sometimes is more than one character. Also remove "DRAW_" prefix from character
names, TREE_* and ARROW and BLACK_CIRCLE are unambigous on their own, don't
draw anything, and are always used as an argument to special_glyph().
Rename "DASH" to "MDASH", as there's more than one type of dash.
This allows selecting the propagation level of emitted LLDP packets
(specifically: the destination MAC address of the packets). This is useful
because it allows generating LLDP packets that optionally cross certain types
of bridges.
See 802.11ab-2009, Table 7-1 for details.
networkd: add support to set route table
1. add support to configure the table id.
if id is less than 256 we can fit this in the header of route as
netlink property is a char. But in kernel this proepty is a
unsigned 32. Hence if greater that 256 add this as RTA_TABLE
attribute.
2. we are not setting the address family now. Now set this property.
Separate fields are replaced with a struct.
Second second duid type field is removed. The first field was used to carry
the result of DUIDType= configuration, and the second was either a copy of
this, or contained the type extracted from DuidRawData. The semantics are changed
so that the type specified in DUIDType is always used. DUIDRawData= no longer
overrides the type setting.
The networkd code is now more constrained than the sd-dhcp code:
DUIDRawData cannot have 0 length, length 0 is treated the same as unsetting.
Likewise, it is not possible to set a DUIDType=0. If it ever becomes necessary
to set type=0 or a zero-length duid, the code can be changed to support that.
Nevertheless, I think that's unlikely.
This addresses #3127 § 1 and 3.
v2:
- rename DUID.duid, DUID.duid_len to DUID.raw_data, DUID.raw_data_len
Both versions of the code are changed to allow the caller to override
DUID using simple rules: duid type and value may be specified, in
which case the caller is responsible to providing the contents,
or just duid type may be specified as DUID_TYPE_EN, in which case we
we fill in the values. In the future more support for other types may
be added, e.g. DUID_TYPE_LLT.
There still remains and ugly discrepancy between dhcp4 and dhcp6 code:
dhcp6 has sd_dhcp6_client_set_duid and sd_dhcp6_client_set_iaid and
requires client->state to be DHCP6_STATE_STOPPED, while dhcp4 has
sd_dhcp_client_set_iaid_duid and will reconfigure the client if it
is not stopped. This commit doesn't touch that part.
This addresses #3127 § 2.
Header files were organized in a way where the includer would add various
typedefs used by the includee before including it, resulting in a tangled
web of dependencies between files.
Replace this with the following logic:
networkd.h
/ \
networkd-link.h \
networkd-ipv4ll.h--\__\
networkd-fdb.h \
networkd-network.h netword-netdev-*.h
networkd-route.h \
networkd-netdev.h
If a pointer to a structure defined in a different header file is needed,
use a typedef line instead of including the whole header.
Let's move DUID configuration into the [DHCP] section, since it only makes
sense in a DHCP context, and should be close to the configuration of
ClientIdentifier= and suchlike.
This really shouldn't be a section of its own, we don't have any for any of our
other per-protocol specific identifiers...
Follow-up for #2890#2943
