For exported connections, nm_settings_connection_interface_update() is
supposed to cause the emission of a
NM_SETTINGS_CONNECTION_INTERFACE_UPDATED signal. This is usually done
by chaining up to the NMExportedConnection implementation of this
method, which actually emits the signal. However, the
NMKeyfileConnection implementation usually forgot to do this. Rewrite
so that we always chain up after successfully saving settings.
The wifi device is considered to be 'scanning' if the supplicant emits
the scanning signal or if it's in the scanning state; but the code
didn't correctly handle notifications when the supplicant was in the
scanning state.
This reverts commit b172519045.
When something like NTP updates the system clock, that can cause
dhclient to expire the lease, and at that point we just want NM
to let dhclient re-aquire the lease instead of failing the
whole connection.
Even though we prefer NetworkManager.conf, we need to check the
old nm-system-settings.conf first to preserve compat with older
setups. In package managed systems dropping a NetworkManager.conf
onto the system would make NM use it instead of nm-system-settings.conf,
changing behavior during an upgrade. We don't want that.
The PPP setting will usually be all defaults anyway, so lets just
created it when needed if it doesn't yet exist. Fixes an error
where the connection editor couldn't edit system DSL connections
because it tried to request secrets for the PPP setting that didn't
actually exist in the connection because the 'keyfile' plugin
wouldn't save all-default settings, thus that setting wouldn't
exist when read back in.
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.
PK's "allow_inactive" actually means "allow inactive *local* users", so
we do want to allow inactive local users to provide user connections.
We don't want to allow non-local inactive users to provide user connections.
So make the use-user-connections privilege match for both active and
inactive so we get the behavior we want.
Monitor the kernel firmware directory (set at configure-time with
--with-kernel-firmware-dir=<path>) for changes, and if there
are any, try bringing up devices that are missing firmware.
If an NMObject listened to property change notifications from
other NMObjects and then in response to that queued up other
property changes of it's own, those would get added to the
property change list that was being iterated through already.
Each name in the change list is freed after being notified,
but the change list itself is actually freed when all
properties have been notified. So an object that queues up
another change notification ends up in _nm_object_queue_notify()
which iterates the change list where half of the data elements
are already freed...
Not all drivers will return errors when even when they don't provide
the GPERMADDR ethtool call; sometimes you'll get 00:00:00:00:00:00
which is clearly not right. In this case, fall back to the current
HW address just like if the ethtool GPERMADDR call failed.
- Just use a byte array to old MAC addresses so we don't need to
use .ether_addr_octet everywhere
- Consolidate setting the current MAC address into one location
- Make sure that if the GPERMADDR call fails we use the current MAC
(this wasn't done for wired devices)
- Make log messages consistent
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.
Otherwise glibc will count the localhost IPv6 (::1) mapping as
resolving to the IPv4 localhost mapping as well, so this:
127.0.0.1 localhost.localdomain localhost
::1 foobar localhost6.localdomain6 localhost6
192.168.1.2 fooar
causes a lookup of 'foobar' (or even just 'ping foobar') to resolve
to 127.0.0.1, even though the hostname is *not* listed on the
IPv4 localhost line. Apparently glibc just looks for the hostname
on any IPv4 or IPv6 localhost line.
We need to ensure that even if you don't have a routable IP address
for one of [IPv4, IPv6] that the hostname resolves to the localhost
address for that IP version, otherwise lots of stuff starts
breaking. But for the IP versions that you do have a routable IP
address, we want the hostname to map to that IP address too.
