* Error setting UUIDs discovery filter on big endian systems
@ 2018-12-03 13:56 Matt
2018-12-04 19:53 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 8+ messages in thread
From: Matt @ 2018-12-03 13:56 UTC (permalink / raw)
To: linux-bluetooth
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.
Thank you for your help and attention,
Matt
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error setting UUIDs discovery filter on big endian systems
2018-12-03 13:56 Error setting UUIDs discovery filter on big endian systems Matt
@ 2018-12-04 19:53 ` Luiz Augusto von Dentz
2018-12-05 0:27 ` Matt
0 siblings, 1 reply; 8+ messages in thread
From: Luiz Augusto von Dentz @ 2018-12-04 19:53 UTC (permalink / raw)
To: mwtaylor; +Cc: linux-bluetooth
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.
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error setting UUIDs discovery filter on big endian systems
2018-12-04 19:53 ` Luiz Augusto von Dentz
@ 2018-12-05 0:27 ` Matt
2019-03-05 18:02 ` Matt
0 siblings, 1 reply; 8+ messages in thread
From: Matt @ 2018-12-05 0:27 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error setting UUIDs discovery filter on big endian systems
2018-12-05 0:27 ` Matt
@ 2019-03-05 18:02 ` Matt
2019-03-06 11:10 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 8+ messages in thread
From: Matt @ 2019-03-05 18:02 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error setting UUIDs discovery filter on big endian systems
2019-03-05 18:02 ` Matt
@ 2019-03-06 11:10 ` Luiz Augusto von Dentz
2019-03-06 13:48 ` Matt
0 siblings, 1 reply; 8+ messages in thread
From: Luiz Augusto von Dentz @ 2019-03-06 11:10 UTC (permalink / raw)
To: Matt; +Cc: linux-bluetooth
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error setting UUIDs discovery filter on big endian systems
2019-03-06 11:10 ` Luiz Augusto von Dentz
@ 2019-03-06 13:48 ` Matt
2019-03-06 14:14 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 8+ messages in thread
From: Matt @ 2019-03-06 13:48 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
On 06/03/2019 11:10, Luiz Augusto von Dentz wrote:
> 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
Thanks for pointing me to this line, removing the __le16_to_cpu() does
seem to fix the UUIDs filter scanning on my big endian hardware, I'm not
sure why it is needed, perhaps removing it would break LE hardware or
some other case but I would imagine __le16_to_cpu() would do nothing in
the LE case anyway. I have made this patch to my kernel (4.9) that seems
to be all is needed for me to fix the issue (no changes to bluez):
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index ba24f61..507d996 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -3599,7 +3599,7 @@ static int start_service_discovery(struct sock
*sk, struct hci_dev *hdev,
goto failed;
}
- uuid_count = __le16_to_cpu(cp->uuid_count);
+ uuid_count = cp->uuid_count;
if (uuid_count > max_uuid_count) {
BT_ERR("service_discovery: too big uuid_count value %u",
uuid_count);
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Error setting UUIDs discovery filter on big endian systems
2019-03-06 13:48 ` Matt
@ 2019-03-06 14:14 ` Luiz Augusto von Dentz
2019-03-06 15:14 ` Matt
0 siblings, 1 reply; 8+ messages in thread
From: Luiz Augusto von Dentz @ 2019-03-06 14:14 UTC (permalink / raw)
To: Matt; +Cc: linux-bluetooth
Hi Matt,
On Wed, Mar 6, 2019 at 3:48 PM Matt <mwtaylor@gmail.com> wrote:
>
> On 06/03/2019 11:10, Luiz Augusto von Dentz wrote:
> > 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
>
> Thanks for pointing me to this line, removing the __le16_to_cpu() does
> seem to fix the UUIDs filter scanning on my big endian hardware, I'm not
> sure why it is needed, perhaps removing it would break LE hardware or
> some other case but I would imagine __le16_to_cpu() would do nothing in
> the LE case anyway. I have made this patch to my kernel (4.9) that seems
> to be all is needed for me to fix the issue (no changes to bluez):
Check the patch Ive just sent, your initial fix is actually correct
but since you change it to little endian you had to convert it back
when calculating the length of message otherwise you end up with an
invalid size.
The kernel is actually assuming Little Endian as this is a convention
for Bluetooth protocols.
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index ba24f61..507d996 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -3599,7 +3599,7 @@ static int start_service_discovery(struct sock
> *sk, struct hci_dev *hdev,
> goto failed;
> }
>
> - uuid_count = __le16_to_cpu(cp->uuid_count);
> + uuid_count = cp->uuid_count;
> if (uuid_count > max_uuid_count) {
> BT_ERR("service_discovery: too big uuid_count value %u",
> uuid_count);
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error setting UUIDs discovery filter on big endian systems
2019-03-06 14:14 ` Luiz Augusto von Dentz
@ 2019-03-06 15:14 ` Matt
0 siblings, 0 replies; 8+ messages in thread
From: Matt @ 2019-03-06 15:14 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
On 06/03/2019 14:14, Luiz Augusto von Dentz wrote:
> Hi Matt,
> On Wed, Mar 6, 2019 at 3:48 PM Matt <mwtaylor@gmail.com> wrote:
>> On 06/03/2019 11:10, Luiz Augusto von Dentz wrote:
>>> 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
>> Thanks for pointing me to this line, removing the __le16_to_cpu() does
>> seem to fix the UUIDs filter scanning on my big endian hardware, I'm not
>> sure why it is needed, perhaps removing it would break LE hardware or
>> some other case but I would imagine __le16_to_cpu() would do nothing in
>> the LE case anyway. I have made this patch to my kernel (4.9) that seems
>> to be all is needed for me to fix the issue (no changes to bluez):
> Check the patch Ive just sent, your initial fix is actually correct
> but since you change it to little endian you had to convert it back
> when calculating the length of message otherwise you end up with an
> invalid size.
The patch you sent works, thanks. (Sorry, I missed it as I wasn't
subscribed to the mailing list but looking at the archive.)
>
> The kernel is actually assuming Little Endian as this is a convention
> for Bluetooth protocols.
Ok, that would explain it then.
Many thanks for your help,
Matt
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-03-06 15:14 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-03 13:56 Error setting UUIDs discovery filter on big endian systems Matt
2018-12-04 19:53 ` Luiz Augusto von Dentz
2018-12-05 0:27 ` Matt
2019-03-05 18:02 ` Matt
2019-03-06 11:10 ` Luiz Augusto von Dentz
2019-03-06 13:48 ` Matt
2019-03-06 14:14 ` Luiz Augusto von Dentz
2019-03-06 15:14 ` Matt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).