On 06/03/2019 14:14, Luiz Augusto von Dentz wrote:
Hi Matt,
On Wed, Mar 6, 2019 at 3:48 PM Matt <mwtaylor@xxxxxxxxx> 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
