Sometimes cause the cache not to refill with all interfaces,
meaning NM sometimes got the wrong carrier state from the
kernel which prevented NM from taking over existing connections.
nm_device_set_use_dhcp() and nm_device_get_use_dhcp() were somewhat
confusing and don't really reflect the new DHCP architecture with
NMDHCPClient. Now that timeout and state signals are specific to
the NMDHCPClient it doesn't make sense to check for DHCP use
in the callbacks for those signals since they'll never get called
if DHCP isn't in use. We might as well just keep the DHCP manager
around and check whether a DHCP client instance exists when we need
to figure out whether DHCP is in use.
Since the same interface could be used for both DHCPv4 and DHCPv6 we
can't just use 'iface' for tracking DHCP client lease changes. Instead
use a generated client ID, and track DHCP events based on the client's
PID instead of interface name.
NM shouldn't really be calling Enable(False) except in response to
direct user requests to turn off WWAN, much like rfkill, since
Enable(False) /is/ essentially rfkill for 3G. Instead, we should
be powering up the modem before trying to use it, and only
disconnecting after we're done. Let the user do enable/disable
when they want to.
This also fixes issues with other devices like GPS potentially
using the modem-manager at the same time as NM and ensures that NM
won't punch the modem in the face while GPS is using it.
And remove cargo-culted internal stuff which is no longer needed.
The ifcfg-rh sha1 stuff wasn't even used anymore after the move to
certificate paths.
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.
