Otherwise if another connection was subsequently activated on a
bond interface, and didn't specify all options, ones set for the
previous connection could stay set for the new connection.
Make sure we don't already have an NMDevice for this interface
before creating it, and also when creating the interface, make
a new NMDevice for it immediately to prevent a race between
telling the kernel to create the interface via netlink, and when
udev later tells us about it. In between there we could be
triggered to try creating the interface again.
First make it build on libnl1/2. Second, the VLAN
virtual interface name might not always be given in the
NMConnection (if the master is a UUID and thus the name
is determined automatically) so just take the interface
name instead. And make sure we verify it's a VLAN
interface before deleting it.
Lastly, construct the VLAN interface name if it's not
given in the NMConnection. This means we need to know
the master interface name when creating the connection,
which we always will since you can't create the VLAN
interface without it's master being present. That also
means we need to return the name to the caller so it
can be used to create the NMDevice for the VLAN interface
after we've created it in the kernel.
We make use of libnl (>=3.2.1) to create/delete kernel vlan device,
and it can set vlan id, vlan flags and ingress/egress priority mapping.
V3:
1 nm_netlink_iface_to_index() should use slave name
V2:
1 use existing nm_netlink_iface_to_index()
Signed-off-by: Weiping Pan <wpan@redhat.com>
Adds a new function nm_system_apply_bonding_config() which applies
the parameters specified in the NMSettingBond object via sysfs.
Calls that function after creating/updating the bonding master
device.
If a parameter is not specified in the ifcfg the parameter will be
re-initialized to the default value. This may overwrite changes
which have been done manually via sysfs but it is the only reliable
way of setting up the bond.
Supported parameters for now:
- mode (default: balance-rr)
- miimon (default: 100)
- updelay (default: 0)
- downdelay (default: 0)
- arp_interval (default: 0)
- arp_ip_target (default: none)
Thomas Graf <tgraf@redhat.com>
Kills the strdup() and avoids having the caller free the memory. Also renames
the function to nm_system_get_iface_type() since "link" is not a common term
in NM.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Code is written generic enough to allow easy addition of further master/slave
relationships such as bridging relations.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
(whitespace cleanups and libnl compat by dcbw)
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>
If configuration fails, there won't be an IPv6 config for the device,
thus the route flush when deactivating the device if it fails would
only flush IPv4 routes. We don't know how far through IPv6 setup
we got, so we do want to flush IPv6 routes on deactivate if we
started IPv6 config at any point.
DHCPv6 doesn't really use broadcast; instead clients use reserved
multicast addresses to talk to the server. ff02::1:2 (link scope)
and ff05::1:3 (site scope) are used. This means the routing table
has to have a route that can handle outgoing traffic to these
addresses, which is ff00::/8. The kernel sometimes adds one for us,
so we need to (a) make sure we don't tear that route down, and
(b) that if it's not there before we start DHCPv6, that we add it.
Otherwise dhclient complains about not being able to send outgoing
traffic from it's send_packet6() function with "no route to host".
It will then use an expired lease, which causes NM to assign that
leases IP address to the interface, whcih causes the kernel to
assign the required ff00::/8 route, and then dhclient performs a
renew (since the expired lease has expired of course) and then
everything works out in the end. But the latency sucks.
So make DHCPv6 faster by ensuring that dhclient has the routes
it needs before we start the DHCP session.
This commit implements MAC cloning feature in NetworkManager. To support that,
'PermHwAddress' property is added into *.Device.Wired and *.Device.Wireless
interfaces. The permanent MAC address is obtained when creating the device, and
is used for 'locking' connections to the device. If a cloned MAC is specified
in connection to be activated, the MAC is set to the interface in stage1. While
disconecting, the permanent MAC is set back to the interface.
Use the interfaces kernel index when we can to avoid unecessary
iface->index lookups; and let callers figure out which address
family they really want to flush.
