Open potto216 opened 7 months ago
@surban Would looking at the d-bus messages be the next step?
Yes, and if they seem to be correct it would help to see what is going on in bluetoothd
.
I see the same behavior with bluetoothctl
ignoring the advertisement min/max interval values. Attached are two files. The first advertising_interval_fail_bluetoothctl.txt has the output running and monitoring bluetoothctl
. The second advertising_interval_fail_bluer.txt is running and monitoring the le advertising program using Bluer. Both output files are composed of the program output, the btmon output and the dbus output. To capture the dbus output I used
sudo dbus-monitor --system "type='signal',sender='org.bluez'"
Because these showed nothing when running the programs
sudo dbus-monitor --system "type='signal',destination='org.bluez'"
sudo dbus-monitor --system "type='signal',destination='org.bluez',sender='org.bluez'"
I looked for the dbus org.bluez.LEAdvertisement because it has advertising interval setting uint32 MinInterval [Experimental]
and uint32 MaxInterval [Experimental]
.
When looking at both output, I saw the HCI command with the default min max interval parms:
< HCI Command: LE Set Extended Advertising Paramet.. (0x08|0x0036) plen 25 #1 [hci0] 44.213445
Handle: 0x01
Properties: 0x0013
Connectable
Scannable
Use legacy advertising PDUs: ADV_IND
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: Host has no preference (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
And the dbus message for bluetoothctl of
string "type='signal',sender=':1.119',path='/org/bluez/advertising',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',arg0='org.bluez.LEAdvertisement1'"
# and
method call time=1714311596.212997 sender=:1.106 -> destination=:1.119 serial=181 path=/org/bluez/advertising; interface=org.freedesktop.DBus.Properties; member=GetAll
string "org.bluez.LEAdvertisement1"
and for bluer program of
string "type='signal',sender=':1.116',path='/org/bluez/bluer/advertising/b0191643d3f3434eae417bfce7019e12',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',arg0='org.bluez.LEAdvertisement1'"
method call time=1714311418.842087 sender=:1.106 -> destination=org.freedesktop.DBus serial=143 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
string ":1.116"
uint32 0
method call time=1714311418.842484 sender=:1.106 -> destination=:1.116 serial=144 path=/org/bluez/bluer/advertising/b0191643d3f3434eae417bfce7019e12; interface=org.freedesktop.DBus.ObjectManager; member=GetManagedObjects
method call time=1714311418.843584 sender=:1.106 -> destination=:1.116 serial=145 path=/org/bluez/bluer/advertising/b0191643d3f3434eae417bfce7019e12; interface=org.freedesktop.DBus.Properties; member=GetAll
string "org.bluez.LEAdvertisement1"
signal time=1714311418.854776 sender=:1.106 -> destination=(null destination) serial=146 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.bluez.LEAdvertisingManager1"
array [
dict entry(
string "SupportedInstances"
variant byte 5
)
dict entry(
string "ActiveInstances"
variant byte 1
)
]
array [
]
method call time=1714311431.767501 sender=:1.106 -> destination=org.freedesktop.DBus serial=151 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
string "type='signal',sender=':1.116',path='/org/bluez/bluer/advertising/b0191643d3f3434eae417bfce7019e12',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',arg0='org.bluez.LEAdvertisement1'"
It looks to me that that the min/max intervals are never sent so the defaults are used (but I'm not very familiar with dbus messages). However, I see in the bluer code in Advertisement function register_interface that they are sent.
@surban do you think this is enough evidence of a bluez issue to file an issue with them?
@surban do you think this is enough evidence of a bluez issue to file an issue with them?
Yes, seems to be a bluetoothd bug.
I added the issue https://github.com/bluez/bluez/issues/833
@potto216 hello I have a same problem with you,then i try to use this cmds: 1、first step echo 153 > /sys/kernel/debug/bluetooth/hci0/adv_min_interval echo 153 > /sys/kernel/debug/bluetooth/hci0/adv_max_interval, 2、next /usr/libexec/bluetooth/bluetoothd without -E -d 3、last bluetoothctl>advertise.name xxx>advertise on then use nrfconnect start scan you will get the ble name xxx and obverse the more item you can see the adv interval value is changed.
I'm seeing the same problem as issue #21. I'm running on Debian and with Blue Z 5.74
And experimental features (although the same issue happens without them)
And when I advertise using the program
https://github.com/potto216/bluer-cmd/blob/main/le_advertise/src/main.rs
with the command lineI see the advertisement has the min/max interval between 600 msec and 900 msec
Advertisement { advertisement_type: Broadcast, service_uuids: {123e4567-e89b-12d3-a456-426614174000}, manufacturer_data: {}, solicit_uuids: {}, service_data: {}, advertising_data: {}, discoverable: Some(false), discoverable_timeout: None, system_includes: {}, local_name: None, appearance: None, duration: None, timeout: None, secondary_channel: None, min_interval: Some(600ms), max_interval: Some(900ms), tx_power: None, _non_exhaustive: () }
But the HCI with
btmon
shows it is being ignoredand over the air captures show the advertisement is being ignored.
@surban Would looking at the d-bus messages be the next step?