- 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.
device_start() would unconditionally transition the device to UNAVAILABLE
no matter what the initial managed setting was. There was a short window
for a race with HAL where device_start() wouldn't get canceled if HAL
was starting up in parallel with NetworkManager.
Fix issues with crappy wifi drivers which send a stream of associate
events before NM can schedule the next activation stage, which actually
scheduled *multiple* next stages. Only allow one stage to be scheduled at
at time, and don't schedule the same stage again if it's already next up
to the plate.
Fake APs created in nm_ap_new_fake_from_connection() didn't get the
right flags due to wrong interpretation of # WPA protos; no protos really
means "all ciphers". Thus the applet wouldn't ask for the right type of
security info if the connection failed; for hidden WPA networks, the applet
would instead ask for WEP keys.
Clean up addition of flags for 'fake' WPA APs in general; pairwise
shouldn't ever include WEP ciphers, and if the connection didn't
include any pairwise or group ciphers, default to "all" as is
expected. Also fix flags for WPA Ad-Hoc networks, since they have
special limitations imposed by the supplicant and drivers.
The first fix didn't cover creating a new adhoc network while already joined
to an existing adhoc network; thus clearing the 'fake' flag wouldn't necessarily
drop the old adhoc network from the scan list, because NM doesn't scan in adhoc
mode, and thus the scan list culling function wouldn't run.
Even if the AP being removed isn't adhoc, it was never found from a scan anyway
(if it had, the fake flag would have been reset) and thus we don't care about
it anymore.
Since NM doesn't scan while associated with an Ad-Hoc BSS (since
scanning in adhoc mode makes most driver quite angry and doesn't
work well anyway) the user-created BSS was never found in the scan
list, and the 'fake' flag wasn't cleared. Thus the BSS stuck
around in NM's scan list forever.
Additionally, ensure that set_current_ap() maintains a reference
to the old AP until after setting the new AP, just in case the same
AP is being set again.
Third, handle IBSS coalescing by always updating the current AP's
address (if it's an Ad-Hoc AP) with the BSSID reported by the card.
The joined Ad-Hoc networks' BSSID will change if the card
coalesces with other stations in the same IBSS, which would make
NM fail to find the currently joined network in the scan list, and
lead to "roamed to (none)" messages and inability to find the
current AP.
Fixes a crash with PropertyChanged signals (triggered when using wifi + vpn and
rmmod-ing the driver) where properties_changed_info_destroy() wouldn't get
called on object destruction becuase the GObject finalize method never got
called for the DHCP4Config and IP4Config objects.
We really have wanted to use IFF_LOWER_UP since 2.6.17 for carrier
status, since that's tied to netif_carrier_ok()/netif_carrier_on() in
the kernel. See kernel commit b00055aacdb172c05067612278ba27265fcd05ce
for the introduction of IFF_LOWER_UP.
Previously requiring only v1 was possible, but there are apparently
so many different implementations of v1 that sometimes you have to force
v0 instead.
