Re: Error setting UUIDs discovery filter on big endian systems

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

Hi Matt,

Looks like the kernel is indeed assuming the length is in LE:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/mgmt.c#n3958

Not sure about the error returned though, perhaps the hdr length is
not properly converted to LE.

On Tue, Mar 5, 2019 at 8:02 PM Matt <mwtaylor@gmail.com> wrote:
>
> 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@gmail.com> 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



-- 
Luiz Augusto von Dentz