The ipw2x00 drivers won't be converted over to the kernel's rfkill
subsystem until 2.6.33, and thus listening for udev rfkill change
events on these devices doesn't work. So until then, poll rfkill
state for ipw2x00 devices every few seconds in addition to listening
to other rfkill sources.
Shouldn't be allowing scan requests when associating or when the
supplicant is otherwise busy doing something else.
Older fullmac cards are much more likely to run into this problem
since they usually take longer to connect; since they take so
long, NM may sometimes request a scan during association or
during DHCP which can cause the card to miss DHCP replies. I've
never seen this happen with mac80211 drivers though.
Since rfkill state is saved but not acted upon during sleep
(since NM shouldn't be touching devices while sleeping) we have to
remember to act on the new state when waking up.
3rd patch in a series with:
0bbdc6b0fcb135fa3265
With NM 0.8 the system settings service was integrated into NM and
thus nm_connection_clear_secrets() acts directly on the system
settings plugins' NMConnection objects. So when NM cleared secrets
(for example after determining that they might be bad in a device's
stage2 handler), we completely lost the secrets forever.
With this commit, the secrets are now cached and updated whenever
the connection is updated, and thus are again available to send to
NetworkManager when needed.
nm_connection_replace_settings() replaces the connection's settings
but doesn't allow interception of the new settings. Plugins would then
send out the update signal, but secrets are scrubbed out of them to
ensure secrets aren't leaked out into D-Bus signals.
With NM 0.8 the system settings service was integrated into NM and
thus nm_connection_clear_secrets() acts directly on the system
settings plugins' NMConnection objects. So when NM cleared secrets
(for example after determining that they might be bad in a device's
stage2 handler), we completely lost the secrets forever.
Adding this function allows the system settings service to hook into
the connection updates when the plugin connection's backing storage
(like config files or whatever) changes and cache the secrets for
use in NMSettingsConnectionInterface get_secrets() requestes.
Turn DHCP and DNS debugging on with NM_DNSMASQ_DEBUG.
Without --strict-order, dnsmasq will round-robin queries which in
the case of VPN connections may result in the query going to the
non-VPN nameserver. Also, allow dnsmasq to poll resolv.conf for
nameserver updates so that when the default connection changes,
it knows about the new nameservers.
If the supplicant interface became ready but the device was still
UNAVAILABLE, requesting a scan before transitioning to DISCONNECTED
would just fail because can_scan() returns FALSE when the device's
state is not >= DISCONNECTED. Change device state first so that
doesn't happen.
Impact of this bug is likely limited to Ad-Hoc connections that don't
require a scan before activation since by the time the scan has finished,
the NMSupplicantInterface will be set up. However, this shows a bug where
Ad-Hoc connections can be immediately activated even if they don't have
the latest timestamp, because a scan hasn't completed yet and thus we don't
know if there are any usable APs around. Could be fixed by only letting
auto-activations happen after the first successful scan anyway. But whatever...
Log messages look like this:
NetworkManager: <info> Activation (wlan0/wireless): connection 'Wireless connection 1' requires no security. No secrets needed.
NetworkManager: <info> Config: added 'ssid' value 'foobar'
NetworkManager: <info> Config: added 'mode' value '1'
NetworkManager: <info> Config: added 'frequency' value '2412'
NetworkManager: <info> Config: added 'key_mgmt' value 'NONE'
(NetworkManager:28239): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
(NetworkManager:28239): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion `instance != NULL && instance->g_class != NULL' failed
NetworkManager: dbus_g_proxy_begin_call: assertion `DBUS_IS_G_PROXY (proxy)' failed
NetworkManager: <WARN> real_act_stage2_config(): Activation (wlan0/wireless): couldn't send wireless configuration to the supplicant.
NetworkManager: <info> (wlan0): device state change: 5 -> 9 (reason 9)
NetworkManager: <info> Activation (wlan0) failed for access point (foobar)
NetworkManager: <info> Marking connection 'Wireless connection 1' invalid.
This happened because the nm_device_wifi_set_enabled() only checked for
the existence of the NMSupplicantInterface, but not whether the supplicant
interface was ready to be used. The supplicant interface would be in the
middle of the getInterface or addInterface call and wouldn't have
initialized priv->iface_proxy yet, which is where that error message was
coming from.
So don't change device state from the wifi_enabled handler, just init
the supplicant interface (it should have been torn down already by
device_state_changed() when the device goes to UNAVAILABLE or UNMANAGED)
and wait for the supplicant interface state change to READY to change
the NMDeviceWifi state to DISCONNECTED in supplicant_iface_state_cb_handler().
Link against libm (using the LT_LIB_M macro and the $LIBM variable) as
we are using pow() and otherwise fail to build with stricter linkers like
binutils-gold.
The device type is set at object construction before the object is
ever exported, thus the first time a client gets the value it will
be correct, and the value should never change. As such, the
property never needs to be part of PropertiesChanged signals.
Previously, ppp code would flip device state to _NEED_AUTH before
asking for secrets update; this is not the case anymore after landing
of f28a0df4a66e8f6c98327691c9c90df0604bbd28; hence, we need to
allow update of secrets in all ACTIVATING stages.
This patch updates this behaviour for all device classes with ppp
support.
It's a singleton, but PolicyKit didn't increment the reference count
when returning from polkit_authority_get() like we expected (which has
since been fixed upstream). So for now, just don't unref the authority
at all.
Since we don't do that, there's a chance that some PolicyKit calls could
be outstanding when either the NMSysconfigSettings object or one of the
NMSysconfigConnection objects are around, so we make sure we cancel any
PolicyKit calls when the object gets disposed. This is tricky, because
canceling them from the dispose may mean that the callback gets called
after the object is actually destroyed, so we have to be careful not to
access any private object data from the callbacks in that situation.
Based on a patch from Alexander Sack, but hugely
modified by me to make use of allocated realpath results
instead of stack-based arrays, and to fix an omission in
the original patch that would still have used the
non-realpath-resolved path to /etc/resolv.conf when doing
the atomic rename of the tempfile to resolv.conf.
device->want_signal was never set to TRUE when addrconf was started,
causing random netlink events (say for link-local address addition
or removal) to trigger the config-changed signal from
nm_ip6_device_sync_from_netlink() at the wrong time. This would
cause IPv6 address configuration to look like it succeeded, when
in fact the config timeout was still in-force. Thus device
activation would proceed if IPv4 was enabled, but a few seconds later
the device would be deactivated due to the still active IPv6
timeout.
So fix that and clarify when the events from the IPv6 manager happen,
and what the want_signal variable is really for.
The error object passed to the plugin's add-connection handler wasn't
getting properly cleared if an earlier plugin had failed to write
the connection and fell back to the current plugin.
NM previously only cleared secrets when the VPN service daemon quit,
and the service daemons are on a 10-second inactivity timer. So if
the user tried to re-activate the failed VPN connection within 10
seconds the old secrets would get used, which clearly isn't what we
want. Ensure that whenever the VPN connection fails or disconnects,
we ask the settings service for secrets again the next time.
NM didn't pass it to MM anyway, so it was mainly unused, but the band settings
were still wrong. Fix that (and still preserve ABI) by adding a new property
for allowed bands that can actually hold all the bands instead of limiting
to 16-bits. Clean up some of the deprecation stuff at the same time to make
it clearer what's deprecated and what to do about it.
Commit 715ddd2045 broke sharing because
sometimes a multi-argument string gets passed in rule->rule. Revert
most of that commit. A bunch of cleanups by dcbw too.
Fix up refcounting, plus it turns out that we already have the MAC address
lying around as a GObject data item, so we don't need to go grab it
from the connection itself.
An ethernet device that's actually a component of a modem could get
added to the device list, but then destroyed without getting removed
from the device list.
Don't immediately tear down an active wired connection when the carrier
flips to off, but wait a few seconds for it to come back before breaking
the user's network.
In the past networkmanager did not allow to manually disconnect devices.
Manually disconnected devices will not be automatically reconnected until one
of the following events occur:
1. user activates a connection for the currently disconnected device
2. network manager awakes from hibernate/suspend
3. network manager is restarted (e.g. reboot)
Add a Disconnect method to generic NMDevice dbus interface; set a new private
autoconnect_inhibit flag if Disconnect method is called through dbus.
Based on this auto activation for devices gets inhibited until one
of the above events occur.
