The only thing that doesn't work yet is the system-settings service's
"auto eth" connections for ethernet devices that don't have an existing
connection. Might also have issues with unmanaged devices that can't
provide a MAC address until they are brought up, but we'll see.
Plugins no longer need to hash WPA passphrases, so there's no need to keep
sha1 stuff around unless its for hasing other stuff (ifcfg-rh uses sha1
for certificate hashing for example, but has a private copy).
Leave it to wpa_supplicant now; if we can't trust the supplicant to
handle this, then we need to fix the supplicant. It knows better than
us what needs to happen with drivers, and it already clears the
encryption keys anyway.
Fixes a bug where if GSM secrets were required, the connection would fail
because they were requested with SECRETS_CALLER_HSO_GSM, but the function
to handle retrieved secrets only expected SECRETS_CALLER_GSM.
- Re-query the BlueZ manager when connection, or connections are
added
- Don't assert when a new BT device is created
- Fix the connection bdaddr and device bdaddr comparison, we
were comparing a byte array with a string
- Simplify bluez_manager_bdaddr_has_connection()
- Use NM_BT_CAPABILITY_NONE instead of 0 when appropriate
- Don't assert on priv->bt_type not being set in
real_deactivate_quickly(), as it might be called with no
connections activated
- Fix cut'n'paste typo that made setting the device capabilities
assert
Create a new exported Bluetooth device object for any usable Bluez device
that has at least one corresponding NMConnection somewhere. Clean up
UUID/Capability confusion too.
NMSettingBluetooth represents the local connection, and thus should
use "PANU" not NAP, because the local adapter will be in PANU mode.
For now, NAP is only relevant when talking about the *remote* device
in NMDeviceBt or NMBluezDevice.
With supplicant patches, this allows NM to figure out when the supplicant
is performing an unsolicited scan, and thus to not run periodic_update()
when the supplicant is scanning.
This fixes some of the causes of "roaming to none", especially in hidden
SSID networks. In those cases, after NM had requested a broadcast scan,
the hidden SSID AP would likely not show up in the scan results, leading
to the supplicant performing a specific SSID scan that NetworkManager
was unaware of. While that specific SSID scan was going on, NM could
run periodic_update() and pull the wrong frequency off the card,
leading to the "roaming to none" message when the associated AP with
the wrong frequency could not be found in the scan list.
Fix a few issues here:
- nm_utils_merge_ip4_config() didn't reset domains, which would cause domains
to still be used even if the user elected to ignore DHCP-provided DNS
- nm_ip4_config_add_domain() and nm_ip4_config_add_search() didn't filter
duplicates
- nm_ip4_config_reset_searches() leaked everything
- If the user had specified an appended search in the connection, that search
would be added to the 'searches' field in resolv.conf, but any server
returned domains in 'domain_name' would be ignored because at least one
search existed.
When root is at_console, the at_console stuff overrides the user=root
section. Since the default section will deny-by-default, explicitly
allow certain D-Bus interfaces to be usable by at_console users (including
root when root is at_console) prevents root from being denied access to
those interfaces when root is at_console.
Instead of requiring applets to hash passphrases, just do it in NM instead.
This should fix confusion where people don't understand that they are seeing
their hashed passphrase.
