On 05/12/2018 00:27, Matt wrote:
Hi Luiz,
On 04/12/2018 19:53, Luiz Augusto von Dentz wrote:
Hi Matt,
On Mon, Dec 3, 2018 at 3:59 PM Matt <mwtaylor@xxxxxxxxx> wrote:
Hi,
When setting a UUIDs discovery filter I am receiving
"org.bluez.Error.InProgress" on starting a scan (which isn't in
progress
and will not start unless the discovery filter is cleared).
I am using bluez 5.50 (on openWRT). The problem seems to only appear on
big endian hardware (tested a couple of recent kernel and bluez
versions), the same software compiled for and tested on little endian
hardware works as expected. The issue can be reproduced in the
following
way using bluetoothctl:
# /etc/init.d/bluetoothd restart
# bluetoothctl
[bluetooth]# power on
Changing power on succeeded
[CHG] Controller 00:1A:7D:DA:71:13 Powered: yes
[bluetooth]# menu scan
[bluetooth]# uuids 0000180f-0000-1000-8000-00805f9b34fb
[bluetooth]# back
[bluetooth]# scan on
SetDiscoveryFilter success
Failed to start discovery: org.bluez.Error.InProgress
Setting an rssi filter does work as expected on my big endian hardware,
it is only the uuids filter that appears to show this problem. The
issue
appears whether set using bluetoothctl or directly using DBus.
Do you have the bluetoothd logs when that happens? I wonder if it is
something with our string to UUID conversion.
When performing the above sequence in bluetoothctl with 'bluetoothd
-d' I get the following in my log:
daemon.debug bluetoothd[22991]: src/agent.c:agent_ref() 0xb03e60: ref=1
daemon.debug bluetoothd[22991]: src/agent.c:register_agent() agent :1.29
daemon.debug bluetoothd[22991]: src/adapter.c:property_set_mode()
sending Set Powered command for index 0
daemon.debug bluetoothd[22991]:
src/adapter.c:property_set_mode_complete() Success (0x00)
daemon.debug bluetoothd[22991]: src/adapter.c:new_settings_callback()
Settings: 0x00000ad1
daemon.debug bluetoothd[22991]: src/adapter.c:settings_changed()
Changed settings: 0x00000001
daemon.debug bluetoothd[22991]: src/adapter.c:adapter_start() adapter
/org/bluez/hci0 has been enabled
daemon.debug bluetoothd[22991]: src/adapter.c:trigger_passive_scanning()
daemon.debug bluetoothd[22991]: src/adapter.c:set_discovery_filter()
sender :1.29
daemon.debug bluetoothd[22991]:
src/adapter.c:parse_discovery_filter_dict() filtered discovery params:
transport: 7 rssi: 32767 pathloss: 32767 duplicate data: false
daemon.debug bluetoothd[22991]: src/adapter.c:set_discovery_filter()
successfully pre-set filter
daemon.debug bluetoothd[22991]: src/adapter.c:start_discovery() sender
:1.29
daemon.debug bluetoothd[22991]: src/adapter.c:update_discovery_filter()
daemon.debug bluetoothd[22991]:
src/adapter.c:discovery_filter_to_mgmt_cp()
daemon.debug bluetoothd[22991]: src/adapter.c:trigger_start_discovery()
daemon.debug bluetoothd[22991]: src/adapter.c:cancel_passive_scanning()
daemon.debug bluetoothd[22991]: src/adapter.c:start_discovery_timeout()
daemon.debug bluetoothd[22991]:
src/adapter.c:start_discovery_timeout()
adapter->current_discovery_filter == 1
daemon.debug bluetoothd[22991]:
src/adapter.c:start_discovery_timeout() sending
MGMT_OP_START_SERVICE_DISCOVERY 127, 7, 1
daemon.debug bluetoothd[22991]:
src/adapter.c:start_discovery_complete() status 0x0d
kern.err kernel: [709588.482104] Bluetooth: service_discovery:
expected 4100 bytes, got 20 bytes
daemon.debug bluetoothd[22991]: src/agent.c:agent_disconnect() Agent
:1.29 disconnected
daemon.debug bluetoothd[22991]: src/agent.c:agent_destroy() agent :1.29
daemon.debug bluetoothd[22991]: src/agent.c:agent_unref() 0xb03e60: ref=0
If I instead try a uuid filter of 3 uuids in length I get this in the log:
bluetoothd[550]: src/adapter.c:start_discovery_timeout() sending
MGMT_OP_START_SERVICE_DISCOVERY 127, 7, 3
kernel: [1077807.129187] Bluetooth: service_discovery: expected 12292
bytes, got 52 bytes
bluetoothd[550]: src/adapter.c:start_discovery_complete() status 0x0d
So something about the size calculation is going wrong on big endian,
from adapter.c (line 1607) the command is:
|
mgmt_send(adapter->mgmt, MGMT_OP_START_SERVICE_DISCOVERY,
adapter->dev_id, sizeof(*sd_cp) + sd_cp->uuid_count * 16,
sd_cp, start_discovery_complete, adapter, NULL);|
With 1 uuid the bytes expected is being returned as 4100 (should be 4 +
1*16 = 20), with 3 uuids it is 12292 (should be 4 + 3*16 = 52). These
are the numbers that would be returned if the endian of the uuid_count
(or the number 16) was switched, i.e. 1 becomes 256, 3 becomes 768. I'm
not sure why this should be happening.
I have naively tried changing `cp->uuid_count = uuid_count;` to
`cp->uuid_count = htobs(uuid_count);` (line 2079), just to see what
would happen by switching the endian, this stops that kernel error
appearing but just creates an error further along.
bluetoothd[4333]: src/adapter.c:start_discovery_timeout() sending
MGMT_OP_START_SERVICE_DISCOVERY -45, 7, 256
bluetoothd[4333]: src/adapter.c:start_discovery_complete() status 0x03
bluetoothd[4333]: Wrong size of start discovery return parameters
Perhaps there is some place that is just missing some endian switching
that would fix this? Sorry, I am not experienced with bluez or related
code to know where this could be but I would be happy to test any
suggestions or help in some other way with fixing this issue if someone
could advise.
Thanks,
Matt
