Can't get monitor
Closed this issue · 21 comments
let session = bluer::Session::new()
.await
.expect("Failed to connect to bluetooth daemon");
let adapter = session
.default_adapter()
.await
.expect("Failed to get bluetooth adapter");
adapter
.set_powered(true)
.await
.expect("Failed to power bluetooth on");
let monitor = adapter
.monitor()
.await
.expect("Failed to get bluetooth monitor");
Running this crashes with error: DBus error org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterMonitor" with signature "o" on interface "org.bluez.AdvertisementMonitorManager1" doesn't exist
What BlueZ version are you using?
5.70, up to date Arch Linux.
You need to launch your bluetoothd with experimental features enabled, since this is an experimental interface.
let mut monitor_handle = monitor
.register(Monitor {
monitor_type: Type::OrPatterns,
patterns: Some(vec![Pattern {
data_type: 0x0000,
start_position: 0x00,
content: vec![0x00],
}]),
..Default::default()
})
.await
.expect("Failed to register advertisment monitor");
Now this code panics with error kind AdvertisementMonitorRejected and empty message.
Could you check whether this example works for you?
I am not able to get the passive scan example to find the nearby bluetooth advertisers such as
[bluetooth]# [CHG] Device D6:84:50:9E:F9:94 RSSI: 0xffffffa2 (-94)
[bluetooth]# [CHG] Device D6:84:50:9E:F9:94 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[bluetooth]# [CHG] Device D6:84:50:9E:F9:94 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[bluetooth]# [CHG] Device D6:84:50:9E:F9:94 UUIDs: 71262000-3692-ae93-e711-472ba41689c9
when I run
cargo run --example le_passive_scan
Finished dev [unoptimized + debuginfo] target(s) in 1.44s
Running `target/debug/examples/le_passive_scan`
it just runs without displaying anything.
my bluetoothd -v is 5.70 and configured in /usr/lib/systemd/system/bluetooth.service with the line
ExecStart=/usr/libexec/bluetooth/bluetoothd --experimental -d
I also added <allow send_interface="org.bluez.AdvertisementMonitorManager1"/> to /etc/dbus-1/system.d/bluetooth.conf and the user is a member of the bluetooth group
@surban do I need to modify the patterns value?
I have never used the Bluetooth passive monitoring functionality myself.
Maybe @kjetijor can help.
So - there's two things.
-
I may have made an unfortunate choice here by funneling everything through the logging subsystem, and not forcing the logger to at least log at the info level. For that, prepend
RUST_LOG=infosoRUST_LOG=info cargo run --example le_passive_scan --features=bluetoothd -
Yes - you're probably going to have to concoct an "or pattern" for what you're trying to receive, unless it's advertising manufacturer data (0xff, which starts with 0x99, 0x04 at offset 0).
@kjetijor thanks for the help. I am not able to see anything when I run
user@comm-rpi4-01:~/prj/bluetooth/bluer/$ RUST_LOG=info cargo run --example le_passive_scan --features=bluetoothd
Compiling bluer v0.17.0-pre1 (/home/user/prj/bluetooth/bluer/bluer)
Finished dev [unoptimized + debuginfo] target(s) in 17.00s
Running `target/debug/examples/le_passive_scan`
I generated an advertising packet on another device using bluetoothctl and the advertisement configuration:
[bluetooth]# manufacturer 0x99 04
[bluetooth]# manufacturer
Manufacturer: 153
04
And I captured the OTA advertisement which I think should be picked up by the pattern setting.
What are your thoughts as to what could be wrong?
@potto216 You'd need to advertise manufacturer id 0x0499 (or 0x9904 - depending on whether or not bluetoothctl interprets the manufacturer id argument as big or little endian).
With your bluetoothctl advertisement you'd need to change the or-pattern in the example to i.e. vec![0x99] or something similar.
@potto after having slept on that, I think in order to get the LE example to do anything moderately useful - you're going to need an advertisement that changes as well. The way it works today is, when we first see/discover an advertisement that matches the or-pattern, we subscribe to the device that sent it for updates, any subsequent advertisements that come that matches our or-pattern, we get an update event.
I think - with an un-changing advertisement you should hit this print statement but anything in the polling loop needs the advertisement to actually change.
I've tried to get bluetoothctl to generate something useful, without too much luck - so; yea - handcrafted hcitool it is.
I changed the or-filter to something that uses the non-specific manufacturer id 0xffff, and tossed in a few extra bytes.
diff --git a/bluer/examples/le_passive_scan.rs b/bluer/examples/le_passive_scan.rs
index 9cc3479..5660caf 100644
--- a/bluer/examples/le_passive_scan.rs
+++ b/bluer/examples/le_passive_scan.rs
@@ -20,7 +20,7 @@ async fn main() -> bluer::Result<()> {
rssi_low_timeout: None,
rssi_high_timeout: None,
rssi_sampling_period: Some(RssiSamplingPeriod::First),
- patterns: Some(vec![Pattern { data_type: 0xff, start_position: 0x00, content: vec![0x99, 0x04] }]),
+ patterns: Some(vec![ Pattern { data_type: 0xff, start_position: 0x00, content: vec![0xff, 0xff, 0x01, 0xff] } ]),
..Default::default()
})
.await?;
# hciconfig hci1 down
# hciconfig hci1 up
# hciconfig hci1 leadv 0
# hcitool -i hci1 cmd 0x08 0x0008 1E 02 01 1A 06 FF FF FF 01 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
# # wait ** modify this byte
# hcitool -i hci1 cmd 0x08 0x0008 1E 02 01 1A 06 FF FF FF 01 FF 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
# # wait ** modify this byte
# hcitool -i hci1 cmd 0x08 0x0008 1E 02 01 1A 06 FF FF FF 01 FF 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
# cargo run --example le_passive_scan --features=bluetoothd
Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Running `target/debug/examples/le_passive_scan`
Discovered device DeviceId { adapter: "hci0", device: 8C:88:2B:66:6C:7F }
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(Rssi(-68))
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(Rssi(-76))
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(Rssi(-68))
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(Rssi(-78))
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(ManufacturerData({65535: [1, 255, 1]}))
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(Rssi(-68))
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(Rssi(-78))
On device Device { adapter_name: hci0, address: 8C:88:2B:66:6C:7F }, received event PropertyChanged(ManufacturerData({65535: [1, 255, 2]}))
If this works for you - I might actually go ahead and update the example with the or-filter and the hcitool handcrafted monstrosity.
Hi @kjetijor thanks for the help. I'm not getting any output when I run
user@comm-rpi4-01:~/prj/bluetooth/bluer/$ RUST_LOG=info cargo run --example le_passive_scan --features=bluetoothd
Finished dev [unoptimized + debuginfo] target(s) in 0.35s
Running `target/debug/examples/le_passive_scan`
and advertise with
user@comm-rpi3-01:~$ sudo hciconfig hci0 down
user@comm-rpi3-01:~$ sudo hciconfig hci0 up
user@comm-rpi3-01:~$ sudo hciconfig hci0 leadv 0
user@comm-rpi3-01:~$ sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 06 FF FF FF 01 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
< HCI Command: ogf 0x08, ocf 0x0008, plen 32
1E 02 01 1A 06 FF FF FF 01 FF 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 00
user@comm-rpi3-01:~$ sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 06 FF FF FF 01 FF 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
< HCI Command: ogf 0x08, ocf 0x0008, plen 32
1E 02 01 1A 06 FF FF FF 01 FF 01 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 00
user@comm-rpi3-01:~$ sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 06 FF FF FF 01 FF 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
< HCI Command: ogf 0x08, ocf 0x0008, plen 32
1E 02 01 1A 06 FF FF FF 01 FF 02 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 00
Tomorrow I'll try to capture the advertising packets over the air to make sure it is advertising.
No I forgot, I'll try that out tomorrow,
@kjetijor I modified the pattern to be patterns: Some(vec![ Pattern { data_type: 0xff, start_position: 0x00, content: vec![0xff, 0xff, 0x01, 0xff] } ]),
and transmitted the advertising packets over the air (below) but nothing was detected. It looks like I am seeing the changing ADV packets. What are your thoughts?
@potto216 I'm getting to the "I'm at a loss" stage - Do you have multiple bt-interfaces attached ? is the "default interface" the wrong one ?
Does bt passive scanning work with your bt interface and bluez at all ? (I.e. did it work using other bindings to bluez ?) - Having gone through my collection of bt dongles, this is experimental - I have a 50-50 success rate in getting it to work at all, ranging from the "fails with an error", "fails silently" and "occasionally work, after you randomly restart bluetoothd and/or yank/insert the bt dongle".
Well it now works and I'm not sure why, maybe antenna position.
I was able to detect the changes to the advertisements as shown below:
user@comm-rpi4-01:~/prj/bluetooth/bluer/$ RUST_LOG=info cargo run --example le_passive_scan --features=bluetoothd
Finished dev [unoptimized + debuginfo] target(s) in 0.45s
Running `target/debug/examples/le_passive_scan`
Running le_passive_scan on adapter hci0 with or-pattern Pattern { data_type: 255, start_position: 0, content: [255, 255] }
Discovered device DeviceId { adapter: "hci0", device: B8:27:EB:06:4D:1F }
On device Device { adapter_name: hci0, address: B8:27:EB:06:4D:1F }, received event PropertyChanged(ManufacturerData({65535: [1, 255, 1]}))
On device Device { adapter_name: hci0, address: B8:27:EB:06:4D:1F }, received event PropertyChanged(ManufacturerData({65535: [1, 255, 0]}))
Discovered device DeviceId { adapter: "hci0", device: B8:27:EB:06:4D:1F }
Discovered device DeviceId { adapter: "hci0", device: B8:27:EB:06:4D:1F }
On device Device { adapter_name: hci0, address: B8:27:EB:06:4D:1F }, received event PropertyChanged(ManufacturerData({65535: [1, 255, 2]}))
Discovered device DeviceId { adapter: "hci0", device: B8:27:EB:06:4D:1F }
with
patterns: Some(vec![ Pattern { data_type: 0xff, start_position: 0x00, content: vec![0xff, 0xff, 0x01, 0xff] } ]),
and using the HCI commands given by @kjetijor or the following bluetoothctl commands
[bluetooth]# advertise.manufacturer 0xffff 01 0xff 00
[bluetooth]# advertise on
# wait a couple seconds
[bluetooth]# advertise.manufacturer 0xffff 01 0xff 01
# wait a couple seconds
[bluetooth]# advertise.manufacturer 0xffff 01 0xff 02
BTW @kjetijor was it intended that the advertising packets have a lot of zero length advertising elements (below)?
Which seem to be from the HCI_LE_Set_Advertising_Data's Advertising_Data_Length being set to 0x1E so it includes the zero padding in the Advertising_Data parameter (below).
@kjetijor thanks for your help with resolving this.
@potto216 the zero-padding was primarily just an artifact left over from borrowing from a random reply on the internet; I forget where, it may be entirely superfluous.
@LinuxHeki does this now work for you? Can this issue be closed?
I am closing as completed for now, since there has been no response. Feel free to reopen if the issue still exists.