A bonding device is like a virtual ethernet device. We therefore reuse
nm-device-ethernet and add some special handling to detect bonding
connections.
Changes v2:
- Fixed memory leak
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Creates virtual kernel devices as needed. Since the manager is
initialized after the connections have been loaded no
CONNECTIONS_ADDED notification is received for connections parsed
at startup.
Therefore walks the loaded connections looking for bonding
connections.
Connections added on the fly are handled via the notifications.
Connection renaming and deleting is not supported yet.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Introduced a new TYPE=bond for ifcfg-rh configuration files.
Alternatively BONDING_MASTER=yes can be specified instead of
setting the type explicitely to maintain backwards compatibility
with existing configuration files.
Bonding device files require a DEVICE= line to be present which
specifies the virtual bonding interface in the kernel. We do not
allow auto-generation of the name in order to keep confusion to
a minimum when reusing existing bonding interfaces.
The BONDING_OPTS= parameter can be used to specify various bonding
related options, such as:
- mode
- miimon
- updelay
- downdelay
- arp_interval
- arp_ip_target
By default, the NMSettingBond class uses a miimon value of 100 which
seems like a sensible default value for 99% of all configurations.
If this is not suitable, an arp_ip_target needs to be specified
manually.
A writer is not yet implemented.
Changes v2:
- renamed DeviceName property to InterfaceName
- moved code to validate device name to dev_valid_name() for future use
Signed-off-by: Thomas Graf <tgraf@redhat.com>
src/firewall-manager tracks whether firewall is on the bus or not.
In nm-device.c at stage5 (ip-config-commit) before we actually
apply the IP configuration to the interface, we send the
IP interface name and zone to firewall and asynchronously wait
for a D-Bus reply. Then after we get the reply
(or if the firewall isn't running) we proceed with
applying the IP configuration to the interface.
Since both RA and DHCP may be run at the same time, we want to
make sure to merge both configs into a final config when either
RA or DHCP changes. Previously this only happened when RA changed,
but not when DHCP changed or completed. This caused the config
applied when DHCP completed to not contain the RA-derived address,
which was then removed from the device, which then regressed the
IPv6 RA state, causing a device failure.
Found by Tore Anderson
Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f.
Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0'
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23'
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6'
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::'
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87🆎da:5f'
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782'
Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10)
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64'
Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address
Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address')
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address)
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid
Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0
Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23
Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
Initial IP configuration can happen during ACTIVATED state if both
v4 and v6 are enabled, but one takes longer than the other. Thus
various checks throughout the code for IP_CONFIG were incorrect
since they depended on IP configuration only happening during the
IP_CONFIG state. Fix that by using a separate state for IP config
and using that state for various checks instead of the overall
device state.
It was somewhat pointless since the IP config is always known when
stage4 gets scheduled, so why not just pass the config to stage5
immediately? Also helps consolidate the v4/v6 failure handling
logic and makes the operational flow clearer where both v4 and
v6 are active and proceeding in parallel.
We don't really need to wait before both IPv4 and IPv6 are established before
applying all the settings to the device. Instead, we can apply each separately
when they are ready, which will bring up the interface sooner.
So that dhclient will, in turn, pass it to the action script
(the action script tries to send a DBus signal to NetworkManager
over the system bus).
Dhclient "execve"s the action script with a hand-constructed environment
that only includes specific variables, plus whatever is passed to
dhclient with "-e".
As far as I know, dhcpcd has no option equivalent to dhclient's "-e".
