Fixes a crash with PropertyChanged signals (triggered when using wifi + vpn and
rmmod-ing the driver) where properties_changed_info_destroy() wouldn't get
called on object destruction becuase the GObject finalize method never got
called for the DHCP4Config and IP4Config objects.
For the moment; until we can optimize the prober. The problem is that a modem
that's not fully powered up and ready to talk looks exactly the same as a tty
that just doesn't support AT commands at all.
Fix a few problems... No plugin should return secrets in the GetSettings method,
which some plugins did. When that was committed in the commit "system-settings:
don't return secrets in the settings", it broke those plugins that didn't implement
GetSecrets. Each plugin can actually use the same code for GetSettings and
GetSecrets, so implement those generically in the NMExportedConnection class and
remove plugin-specific implementations that all did the same thing.
Some cards are just going to need delayed probing if they take
a bit respond to AT commands after being plugged in. We can
optimize further by doing an initial check, waiting a small time
for the response, then checking again at 1s, waiting a small time,
then checking at 2 seconds and waiting for the full timeout for
those devices where --delay is given.
We really have wanted to use IFF_LOWER_UP since 2.6.17 for carrier
status, since that's tied to netif_carrier_ok()/netif_carrier_on() in
the kernel. See kernel commit b00055aacdb172c05067612278ba27265fcd05ce
for the introduction of IFF_LOWER_UP.
To match 'network' service behavior, which would perform reverse
address lookups when the HOSTNAME from /etc/sysconfig/network
was 'localhost' or 'localhost.localdomain'. Just name your machine
already.
For now. It doesn't make a lot of sense to have modem probing in udev when
we switch to ModemManager in the future, since ModemManager would have to
re-do pretty much everything the udev-extras prober already did. Thus,
since modem-probe from udev-extras doesn't have much of a future, don't
start using it or requiring it. Move the code into NM instead, but still
use udev for the actual probing.
Previously requiring only v1 was possible, but there are apparently
so many different implementations of v1 that sometimes you have to force
v0 instead.
Shutdown on SIGTERM, and don't segfault when quitting cleanly. Can't
send signals on an object that's being disposed of, so don't do that.
Fix a memory leak of the Hal manager's priv->devices on shutdown, not
that it matters.
In combination with udev-extras, this allows automatic detection of modem
capabilties instead of having to keep 10-modem.fdi up-to-date with the hardware
flavor of the week. NMHalManager grabs the originating device of a newly
detected device, passes that to NMManager, which then passes it along to the
device-type-specific creators. The modem creator then asks udev for any
probed modem capabilities, and uses those in perference to any capabilities
HAL reports. HAL capabilities are kept as a fallback.
0.7 requires dbus 1.1 or greater (for system bus activation), so make that
explicit, and remove compat code for D-Bus 0.6 and earlier. Consolidate
the various glib pkgconfig checks into one, since most anything will require
gthread, glib, and gobject anyway. Fixup the docs makefile to be more
automake-compatible and let 'make clean' actually work correctly when
docs are built.
The reconnection timeout would never be canceled, and get rid of the
"disconnected by the system bus" message on exit, which while
technically true was useless due to the pending exit.
While broadcasting WPA and RSN IEs with the Privacy bit set to 0 is
technically illegal, some networks using older Cisco equipment do it
(I'm looking at you, Eduroam) and there's no reason not to support
it. Since the AP is broadcasting WPA/RSN IEs, assume that means
WPA and RSN is supported (duh).
Not actually needed, and actually makes securing the daemon harder
from a D-Bus perspective, since both bus names resolve to the same
unique name anyway, and the unique name is what actually gets
matched on inside dbus. Suggestion from Colin Walters.
This caused the 'autoconnect' property of NMSettingConnection to not
get updated in some cases (as when a system setting plugin noticed a
change to autoconnect=true and emitted the Updated signal, which wouldn't
contain the new value). Add a testcase for setting default values too.