Some configurations won't have a gateway address, because they
are point-to-point (/32). The previous code expected one and
asserted if a gateway was not found; but even without the
assertion, other code expected a non-NULL gateway. Handle that
by defaulting the gateway to 0.0.0.0 (IPv4) or :: (IPv6) and
override that with a better gateway if we have one, otherwise
just use 0.0.0.0/:: since we already know the IP config we're
settings should be the default one.
Add a helper like nm_utils_security_valid() except for access point
mode. We can't use nm_utils_security_valid() without changing the
arguments, hence the new function. Plus in AP mode all you care about
are the device capabilities, not AP flags since the device *is*
the AP.
With both WEXT and nl80211; this wasn't an issue before because
devices can still scan in adhoc mode. But we do need to ensure
that the device is in Infrastructure mode when we deactivate a
Hotspot.
Since the frequency and/or BSSID may not be known immediately, it's
nice to update the export AP object when we do know them, so you
don't end up with missing information like:
SSID BSSID MODE FREQ
'testap' 00:00:00:00:00:00 AP 0 MHz
Note that the "rate" is never updated, because in AP-mode the bitrate
is actually different for each client, so no single rate makes sense.
Scanning doesn't work well in AP mode, because then you're off-channel
and not serving your clients, which isn't good for anyone. Plus,
nl80211 refuses to scan in AP mode anyway, so just don't scan.
Second, track the device's mode based on the connection we're activating
or have activated, not based on whatever mode the kernel drivers are
using that second. That is more consistent, since there's a race between
when the connection starts being activated, when the device will be in
INFRA mode, and when the supplicant actually gets around to changing the
mode.
Third, fix various other codepaths that weren't quite expecting AP mode.
And return an error when trying to activate an AP mode connection
if the supplicant does not support it.
With wpa_supplicant 1.0 and earlier there is no way to positively detect
whether AP mode is supported, so we simply try to start AP mode
and then fail if it doesn't work.
With more recent versions we can check the Introspection data
(if the supplicant has been built with introspection enabled) or
check the global Capabilities (if the supplicant is recent enough)
for positive indication of AP mode support.
A new value for NM80211Mode is introduced (NM_802_11_MODE_AP) and the
new mode is passed to wpa_supplicant analogous to adhoc-mode.
The places which need to know the interface mode have been extended to
handle the new mode.
If the configuration does not contain a fixed frequency, a channel is
selected the same way as with adhoc-mode before.
If async GetProperties completed before the GetConnections, init_left would
be 0 and thus we never connected to connections-read, causing us to terminate
initialization before connections were actually read.
https://bugzilla.gnome.org/show_bug.cgi?id=686226
See http://git.gnome.org/browse/libgsystem/tree/README
for a description of libgsystem.
What we specifically are using it for here is the local allocation
macros; this patch just modifies main.c as a demo.
Note this patch fixes a double-free in an error condition in
check_pidfile(); those sort of mistakes are basically impossible
to make when using these macros.
This breaks a future libgsystem patch. The original use dates
to:
commit ae6f88b3dd
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Aug 24 00:31:47 2004 +0000
Which who knows where it came from or why.
Introduced in 64fd8eea7706038e5d38c8463a1c765ed9331db2; but honestly
I also thought GObject lower-cased signal names since it munges them
for - and _ too. Apparently not.
This implementation uses a delay inhibitor to get systemd to
emit PrepareForSleep, and then emits ::Sleeping and ::Resuming
when receiving the before/after PrepareForSleep emissions.
The gateway doesn't have to be there, but can be associated with
any address. NM should look through all addresses and find the
first usable gateway. Previously it was just using the first
address' gateway even if it was 0.
Broken by 2384dea3 (policy: split routing and DNS updates)
The nm_connection_to_hash() call in the NMSecretAgentGetSecretsFunc
documentation missed the last argument. This patch adds
NM_SETTING_HASH_FLAG_ALL as the last argument in the example.
If D-Bus fails to spawn the supplicant it sometimes returns a method
timeout error instead of a spawn error. We've seen that happen on
F18 when systemd is used to autolaunch the supplicant. That causes
NM to assume that the supplicant crashed and thus never try to talk
to it again, on the assumption that (a) it crashed and (b) it will
crash again if we try to use it, and thus we'll be in a spawn loop.
First, (a) is not necessarily the case, and second, the supplicant
doesn't crash like that anymore. So we're pretty safe to just talk
to the supplicant if it starts later instead of ignoring it if
we detect the timeout error.
NMPolicy was calling nm_device_state_changed() from inside its
NMDevice::state-changed handler, which caused the D-Bus signal to get
lost. Use nm_device_queue_state() instead.
If /etc/NetworkManager/dispatcher.d didn't exist or was
empty, we'd try to pull the first element of a 0-sized array.
To fix this cleanly, we need to explicitly separate discovery
of binaries to execute from setting up the callback data.
