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.
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.
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.
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.
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.
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.
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.
