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.
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.
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)
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.
Rather than having NMDevice subclasses connect to their own
::state-changed signal, fix up the signal definition so they can just
override the class handler.
The idea was copied from gtk, but it's only used there in cases where
the method's wrapper function and default implementation would
otherwise have the same name, which never happens in NM because our
method implementations aren't prefixed with the type name, so it's
just noise here.
VLAN connections can have "hardware" settings in addition to the
VLAN-specific ones. ifcfg-rh was reading in wired settings for VLANs,
but was not writing them back out.
VLANs are only supported on certain kinds of devices, so don't try to
create them on other devices. (In fact, NM currently assumes that
VLANs are only created on Ethernet devices, so we need to be even more
picky than that.)
The ctype macros (eg, isalnum(), tolower()) are locale-dependent. Use
glib's ASCII-only versions instead.
Also, replace isascii() with g_ascii_isprint(), since isascii()
accepts control characters, which isn't what the code wanted in any of
the places where it was using it.
replace_default_ip6_route() was mistakenly requiring gw to be
non-NULL, which meant it could only set the route via a gateway, not
via a device (thus breaking IPv6-over-openconnect)
We don't need to use distribution-specific network scripts to just bring
up the loopback interface.
I'm not aware of any init dependency problems but even if there are some,
it is more practical to solve them in the respective configuration files.
This function also tried to add 127.0.0.1 to the list of addresses but
not ::1. We don't need to set the interfaces up as this is done by the
kernel.
This function was basically the same for all distributions and
was used only in one place. It tried to restart nscd or ask it
to reload configuration. This is not necessary as nscd uses
inotify to watch /etc/resolv.conf.
We go through the SECONDARIES state where we check if there are some secondary
(VPN or other) UUIDs that are to be activated before progressing to ACTIVATED.
In case of an error with a secondary UUID or its activation, the base connection
can't activate successfully.
Recent versions of wpa_supplicant have a "DisconnectReason" property
that, upon a deauthentication event, contains an IEEE 802.11
"Reason Code" for why the disconnect may have occurred. We may
want to use this in the future, so add the infrastructure to pass it
around to supplicant listeners.
Most often, a disconnect during the 4-way handshake means that the
WPA PSK is wrong (though not always). In that case, ask the user
for a new password.
When the supplicant starts connecting, or gets disconnected, track
whether it ever starts talking to an AP. Then if the connection fails
as a result of an initial connection timeout or a link timeout, we
can use SSID_NOT_FOUND when we're reasonably sure the AP doesn't
exist. Clients can use this to show better error messages.
Note that SSID_NOT_FOUND may only be reported when using nl80211
drivers, as WEXT drivers don't provide the status necessary to
determine whether the network exists or not.
