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.
