Some proprietary drivers (wl.o) report tuned frequency (like when
scanning) instead of the associated AP's frequency. This is a great
example of how WEXT is underspecified. We use frequency to find the
active AP in the scan list because some configurations use the same
SSID/BSSID on the 2GHz and 5GHz bands simultaneously, and we need to
make sure we get the right AP in the right band. This configuration
is uncommon though, and the frequency check penalizes closed drivers we
can't fix. Because we're not total dicks, ignore the frequency condition
if the associated BSSID/SSID exists only in one band since that's most
likely the AP we want.
priv->ip_iface gets destroyed in vpn_cleanup() when the class
signal handler handles FAILED/DISCONNECTED, but the dispatcher
is only called *after* that, so it gets a NULL ip_iface. Fix that
so that the dispatcher always gets the tunnel interface for
vpn-up and vpn-down.
dnsmasq may read from its default config file location, which if that
location is a valid config file, it will combine with the options here
and cause undesirable side-effects. Like sending bogus IP addresses
as the gateway or whatever. So give dnsmasq a bogus config file
location to avoid screwing up the configuration we're passing to it.
Since forever we've used sleep/wake as the way to implement
Networking Enabled. When the state file was introduced to make the
networking and wifi states persistent, we ran into a bug where
a failed suspend (like if the machine ran out of power while
suspended) would result in networking being disabled on reboot
since suspend/resume used the same knob as enable/disable.
This patch adds a distinct call for enable/disable networking
which changes the state file, while sleep/wake no longer change
the state file.
All IPv6 enabled sites are expected to provide router advertisement
support apparently. If standalone DHCP is really used in the wild
then we can clearly re-enable it later.
Pad the DNS server expiry somewhat to give a bit of slack in cases
where one RA gets lost or something (which can happen on unreliable
links like wifi where certain types of frames are not retransmitted).
GIO will apparently normally try to use the remote VFS implemenation
on the session bus. But NM (as a root service) shouldn't ever be
trying to talk to anything on the session bus. Squash that.
The kernel apparently caches the value and will send Managed/Other flags
in the newlink message even if the router is no longer reachable and
and RA hasn't been received for a while. So we need to make sure we
check for IF_RA_RCVD before paying attention to Managed/Other.
Since a link-local address should pretty much always be
assigned to an active interface, avoid flushing the routes
that allow link-local communication to work.
Use the interfaces kernel index when we can to avoid unecessary
iface->index lookups; and let callers figure out which address
family they really want to flush.
Previously the input would simply be printed, but if you're not
changing either the level or domains (ie sending "") then the
unchanged logging domains wouldn't be printed, only "".
As long as at least one IP config method completes, and as long as
methods that the user required to complete do complete, allow the
connection to complete.
When the client exits it may take a short amount of time for the
dhclient hook script to deliver the options to NetworkManager; so
we need to keep the client object around a bit (so we know what
NMDHCPClient the options getting delivered are for). If we don't,
the DHCPManager will dispose of the DHCPClient object and then
when the options come in, it can't match up the PID from the
options with the PID of an existing NMDHCPClient. So put the
clients on a removal timer that keeps them around for a bit before
we let the manager dispose of them.
Since we're keeping the PID around too instead of zeroing it when
the client exits (for the reason above), track whether the client
is really dead yet so we don't indiscriminately kill a random
process that happens to re-use the PID.
Ignore early exits of the client in info-only mode; since there is
no address lease the client doesn't need to stick around after
getting DNS/etc options from the server.
Clients in IPv6 info-only mode may exit after getting a response
from the server, since there are no leases involved in info-only
mode. To ensure that the client's options are received when the
event comes in (which could be after we get the child watch
callback for the exit) we still need the client's PID.
