Then, all nexthops managed by networkd really exist (unless the kernel
silently removes a nexthop).
This is the same for nexthop already done by
3c283289ae and
0a0c2672db (for address), and
5d098f5d36 (for neighbor).
The kernel manages nexthops by their IDs. Previously networkd manages
nexthops in three ways:
- by the corresponding link, if a nexthop has ifindex,
- by the manager, if a nexthop does not have ifindex,
- by the manager with their IDs.
This unifies the three managements of nexthops into one, and use the
same way as the kernel uses.
This is the one for nexthop already done by
aa9626ee3b for neighbor.
If a nexthop is requested without a valid ID, then nexthop_acquire_id()
assigns an unused ID. So, at the time nexthop_configure() is called, the
ID is always valid.
The original version would yield a slightly _unexpected_ message for
this [Address] section:
[Address]
Address=10.9.3.1/24
HomeAddress=yes
ManageTemporaryAddress=yes
systemd-networkd[68396]: /run/systemd/network/25-address-static.network: unexpected address flags "n/a" were configured. Ignoring [Address] section from line 144.
Let's instead show the unexpected flags:
systemd-networkd[69160]: /run/systemd/network/25-address-static.network: unexpected address flags "home-address,manage-temporary-address" were configured. Ignoring [Address] section from line 144.
When assert_return() is critical, the following assertion is triggered
on exit:
---
#0 0x00007f8b1f6b0884 in __pthread_kill_implementation () from target:/lib64/libc.so.6
#1 0x00007f8b1f65fafe in raise () from target:/lib64/libc.so.6
#2 0x00007f8b1f64887f in abort () from target:/lib64/libc.so.6
#3 0x00007f8b208d02d6 in log_assert_failed (text=0x7f8b210009e0 "e->state != SD_EVENT_FINISHED", file=0x7f8b20fff403 "src/libsystemd/sd-event/sd-event.c",
line=1252, func=0x7f8b21004400 <__func__.154> "sd_event_add_io") at ../src/basic/log.c:948
#4 0x00007f8b208d0457 in log_assert_failed_return (text=0x7f8b210009e0 "e->state != SD_EVENT_FINISHED",
file=0x7f8b20fff403 "src/libsystemd/sd-event/sd-event.c", line=1252, func=0x7f8b21004400 <__func__.154> "sd_event_add_io") at ../src/basic/log.c:967
#5 0x00007f8b20c7d102 in sd_event_add_io (e=0x617000000080, ret=0x60c000000a20, fd=11, events=1, callback=0x7dfd85 <ipv4acd_on_packet>,
userdata=0x60c000000a00) at ../src/libsystemd/sd-event/sd-event.c:1252
#6 0x00000000007e3934 in sd_ipv4acd_start (acd=0x60c000000a00, reset_conflicts=true) at ../src/libsystemd-network/sd-ipv4acd.c:597
#7 0x00000000007e72b9 in ipv4ll_start_internal (ll=0x6080000006a0, reset_generation=true) at ../src/libsystemd-network/sd-ipv4ll.c:278
#8 0x00000000007e7462 in sd_ipv4ll_start (ll=0x6080000006a0) at ../src/libsystemd-network/sd-ipv4ll.c:298
#9 0x00000000006047a1 in dhcp4_handler (client=0x617000000400, event=0, userdata=0x61a000000680) at ../src/network/networkd-dhcp4.c:1183
#10 0x000000000075b1ed in client_notify (client=0x617000000400, event=0) at ../src/libsystemd-network/sd-dhcp-client.c:783
#11 0x000000000075bf8d in client_stop (client=0x617000000400, error=0) at ../src/libsystemd-network/sd-dhcp-client.c:821
#12 0x000000000077710f in sd_dhcp_client_stop (client=0x617000000400) at ../src/libsystemd-network/sd-dhcp-client.c:2388
#13 0x000000000065cdd1 in link_stop_engines (link=0x61a000000680, may_keep_dhcp=true) at ../src/network/networkd-link.c:336
#14 0x000000000041f214 in manager_free (m=0x618000000080) at ../src/network/networkd-manager.c:613
#15 0x00000000004124e3 in manager_freep (p=0x7f8b1c800040) at ../src/network/networkd-manager.h:128
#16 0x00000000004139f6 in run (argc=1, argv=0x7ffffe4522e8) at ../src/network/networkd.c:24
#17 0x0000000000413b20 in main (argc=1, argv=0x7ffffe4522e8) at ../src/network/networkd.c:119
---
Prompted by https://github.com/systemd/systemd/pull/30049#issuecomment-1844087965.
When an address with peer address is specified, the kernel by default
adds the prefix route for the peer address. When ManageForeignRoute=no
is set, then we also needs to check the prefix for the peer address.
Fixes#30403.
CAN devices do not support IP layer.
Most of the functions below are never called for CAN devices, but
link_set_ipv6_mtu() may be called after setting interface MTU, and warn
about the failure.
For safety, let's unconditionally check if the interface is not a CAN
device.
AllowList= and DenyList= filter only DHCPOFFER messages. So, if
RapidCommit= is enabled, then networkd unconditionally accepts a rapid
ACK message even if its sender is filtered out by the lists.
As AllowList=/DenyList= implemented earlier than RapidCommit=, so
enabling RapidCommit= unconditionally by default may break existing
setups that use AllowList=/DenyList=.
Let's disable RapidCommit= by default when AllowList=/DenyList= is
enabled. Still the setting can be enabled by setting explicitly even
AllowList=/DenyList= is also specified.
When an interface is being reconfigured with different bridge vlan
settings, this makes old vlan IDs on the interface removed.
This also makes the PVID= setting support negative boolean value, e.g. "no",
in which case, the currently assigned PVID (typically, assigned by the
kernel when an interface is joined to a bridge) is dropped.
This feature is requested by #15291.
Note, if a .network file has no settings about bridge vlan, networkd
keeps the currently assigned vlan IDs. That's intended, to make not
break existing setups.
When a .network file has only PVID=no line in [BridgeVLAN] section, then
all assigned vlan IDs are removed.
Fixes#29975.
Closes#15291.
Mike Yuan
Matteo Croce
Yu Watanabe
Frantisek Sumsal
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Topi Miettinen
Daan De Meyer