fix(bluetooth): allow custom adapter in connection settings#492
Conversation
cachebag
added
bluetooth
cachebag
left a comment
cachebag
left a comment
There was a problem hiding this comment.
nmrs/nmrs/src/api/builders/bluetooth.rs
Line 57 in 2f54778
On our bluetooth builders, it still ignores BluetoothIdentity::adapter, so normal builder output cannot exercise the new path anyway.. For instance, a user doing BluetoothIdentity::with_adapter(..., "hci1") then build_bluetooth_connection(...) then add_and_activate_connection(..., None, None) still gets no adapter in the settings map, so this does not really fix the builder workflow.
Perhaps a better approach here that is "non-schema" is probably to derive the BlueZ adapter from the interface argument or resolved NM Bluetooth device when specific_object is None, instead of smuggling adapter through the NM settings dictionary.
| let adapter = section.get("adapter").and_then(|v| match v { | ||
| Value::Str(s) => Some(s.to_string()), | ||
| _ => None, | ||
| }); | ||
|
|
There was a problem hiding this comment.
There is no such thing as adapter on NetworkManagers bluetooth setting.
Since the same settings map is passed unchanged into AddAndActivateConnection, callers would need to include a non-NM key in the profile settings to trigger this behavior. That risks NetworkManager rejecting the connection as an invalid/unknown setting.
|
Thank you for the time you spent reviewing my code. I decided to close this PR because completing it properly requires more advanced knowledge of Rust and this system's architecture than I currently have. I wanted to free up the issue so someone else can take it over. Thanks again for your guidance! |
2 participants
Description
Currently,
add_and_activate_connectionhardcodeshci0for bluetooth device paths, which causes issues on hosts with multiple bluetooth adapters. This PR updates the logic to read theadapterfield from the bluetooth settings section if it is provided.Closes #481