The route metric is one of the object's key attributes and therefore
cannot be left to be chosen by the kernel. Instead, it must always be
specified explicitly. This matches the architecture of libnl3 and the
current API provided by nm-platform.
Previously I didn't think they'd be used for anything other than connection secrets
which only have one hint, but in the future we'll want to pass more information.
Split the agent secrets request tracking structure into a generic
structure for tracking any agent request, and a connection-specific
subclass. We'll use the generic structure in the future for device
secrets and other stuff.
Bonding options are written straight into [bond] group like:
[bond]
interface-name=bbb
mode-active-backup
miimon=300
So we have to handle them explicitly.
We can't clear the ip_iface until after all the routes and addresses
are updated and flushed, because the addresses and routes are
identified by the ip_iface, and if we clear the ip_iface, we don't
know which things to flush anymore.
Example: 'hso' modems have an 'iface' of 'ttyHS4' (a serial port) and
an ip_iface of 'hso0' (an ethernet port). If we clear the ip_iface too
soon, then ip_iface/ip_ifindex is invalid and thus NM has no idea what
to remove, and the default route pointing to 'hso0' sticks around.
This could also happen with other devices where the ip_iface is
different than the iface, like modems, ADSL/ATM devices, etc.
The new setup phase goes like this:
- main()
- parse command line options
- logging is configured, targeting stdout/stderr
- ...other stuff...
- do or do not daemonize, depending on commandline option and config files
- Call openlog() - further log messages go to syslog (and potentially
stderr as well, if the -d option was specified so we use LOG_PERROR).
Basically, this allows us to log messages about config file parsing
and such, which *greatly* helps with debugging.
These assertions (such as getuid() == 0) don't need to access the
config files or commandline arguments, but *do* output localized error
messages, so they should be after setlocale().
Using the new gateway-ping-timeout property, send pings to the first
gateway address until it replies or the timeout is reached, to deal
with dumb hardware that indicates carrier on but doesn't actually
pass traffic.
https://bugzilla.gnome.org/show_bug.cgi?id=702515
Current versions of libnl3 use nl_addr_get_len() instead of
nl_addr_get_prefixlen() to determine the default route. Therefore we're
employing a workaround that sets the address length to zero for default
routes.
Unfortunately this workaround causes nl_addr to have wrong address size,
which in turn requires another workaround in init_ip4_route() as well as
init_ip6_route() to cope with the inconsistency.
Even though this solution is very very ugly, we didn't find a better
one. Not calling rtnl_route_set_dst() didn't solve the problem. Thomas
Graf promised to fix the libnl problem upstream. When bumping dependency
to a version that does this correctly, the workarounds can be removed.
With the move of udev logic into the Linux platform class, the
link-added signals are asynchronous, that is they are not emitted
during the call to nm_platform_*_add(), but after that call has
returned. The Fake implementation still emitted them synchronously,
which broke the testcases. Convert the Fake implementation to emit
link-added signals asynchronously and update the testcases to handle
this.
Just ignore this, since it happens in the current code and is
harmless. While we're here, improve the warning in the case where it
does occur to say whiich state we're overwriting. This should help
debug any future cases.
NM handles the default routes, so they shouldn't show up in the NMIP4Config
for any interface. They get exposed via the 'default' and 'default6' properties
of the ActiveConnection instead.
We have to copy the UUID (key) because otherwise the pointer can be invalidated
when the connection is destroyed and problems will start.
The issue showed up as an unability to delete a conenction via D-Bus.
Reproducer:
$ nmcli con add type eth con-name AAA ifname blah
$ nmcli con delete AAA
$ nmcli con add type eth con-name AAA ifname blah
$ nmcli con delete AAA
-- here the connection is not removed from NM
(even though ifcfg- file) was removed --
Since the platform started using udev for link-added signals, we need
to run the glib mainloop to wait for the udev signals to come in,
instead of expecting them to be emitted immediately.
If things happen just right, where a bond is the first device to use
IPv6 and thus has the only reference to the NMIP6Manager, and the
RTM_NEWROUTE event comes in and triggers manager_request_ip6_info()
but then the device is removed by 'rmmod bonding', the call to
manager_request_ip6_info() could be dangling after the IP6Manager
has been disposed. Fix that.
Due to the hardware address changes in 77dda53b (danw/hwlen) creating
a new Bluetooth device was crashing. The changes there assumed that the
NMDeviceBt's hardware address should only be valid when we were connected
to the device, but that's not quite true. Since we already know the remote
device's Bluetooth hardware address, we already know the hardware address
for the NMDeviceBt as well.
The function only checked whether wimax was enabled (rfkill/user pref)
and whether wimaxd was running. Only nm-device.c calls this function
for WiMAX devices, and the only two uses of it were during activation
(which is already covered by nm-device-wimax.c's is_available() function)
and when the device enters the UNAVAILABLE state, where it is used
to check for missing firmware, which is implemented by the parent
class, not WiMAX.
These turn out to be pretty useless, since their functions are already
covered by each device's state-changed handler or can be done in other
places like deactivate().
https://bugzilla.gnome.org/show_bug.cgi?id=702190
