Not all ethernet devices are immediately usable; newer mobile broadband
devices (Ericsson, Option, Sierra) require setup on the tty before the
ethernet device is usable. 2.6.33 and later kernels set the 'DEVTYPE'
uevent variable which we can use to ignore the interface as a NMDevice
subclass. ModemManager will pick it up though and so we'll handle it
through the mobile broadband stuff.
ifcfg-rh wasn't updated for WEP passphrases after that capability
got added. Can't use KEY for passphrases since there's no way
to distinguish some WEP passphrases from some WEP Hex and ASCII
keys, so we use KEY_PASSPHRASE instead.
The error case was as follows. When using 'ifupdown,keyfile' plugins
and 'eth0' present in /etc/network/interfaces on a Debian-based system,
'ifupdown' plugin, in unmanaged mode, load_connections() prematurely
and thus effectively blocked reading connections from 'keyfile' plugin.
Patch by Dan and tested by me.
This has been around a long time, but is very hard to trigger. It appears
to happen mostly if the supplicant segfaults on resume but has been seen
in other cases as well.
For whatever reason, the DBusGProxy's refcount reaches 0 and the proxy gets
disposed of. That in turn disposes of all the pending calls that are
in-progress on the proxy. Since we give the pending calls a closure, that
closure (nm_supplicant_info_destroy) gets called when the pending calls
are destroyed. That closure unrefs the proxy again.
Since DBusGProxy doesn't have any protection in its dispose() handler
against re-entrant disposes (which is arguably a bug of the client)
we end up infinite looping in nm_supplicant_info_destroy().
Fix that by ensuring we return early if we detect that we are already
freeing the NMSupplicantInfo object, and thus don't try to dispose
of the proxy yet again.
ifcfg-rh plugin was not able to reset MTU to "automatic" if it had been
set to a value, for wired connection. This fix removes "MTU" variable
from the ifcfg-* file when mtu is 0.
RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure
for WIMAX rfkill in the manager's priv->radio_states, we hadn't
filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype
was 0, and thus various operations thought that wifi devices
were wimax devices, and since WiMAX rfkill is never updated because
it's not yet used, wifi would never be enabled after resume.
By default most distros won't log debug messages to syslog; but we
want them logged when the user explicitly requests them via the logging
API and config options in NM. Half the point of doing more logging
was to make it easier for users to get logs out of NM, and having
to edit syslog configuration makes it all pointless.
