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 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
