Hi Johannes, On Tue, Dec 15, 2020 at 6:43 AM Johannes Deisenhofer <jo.deisenhofer@xxxxxxxxx> wrote: > > Hi, > > I could use some help understanding and hopefully fixing a BLE Midi problem. > > I have bought a new MIDI device (Roland GO:Keys). This device connects > fine via BLE, but does not send any key events. I have another keyboard > working fine via BLE. Both devices work with android. > > After digging into code and specs, I think that the chain of events is: > - The MIDI Service is found > - The characteristics are parsed > - The code thinks that all characteristics in the PDU have 16bit UUIDS > (len 7), while 3 of them. are 128bit The spec doesn't allow mixing values of different sizes, or does it first return the 16 bits one and then later 3 are return in a different response? > - Thus it parses nonsense, and does not find the Midi I/O > characteristic, no data transfer possible. > > src/device.c:gatt_debug() MTU exchange complete, with MTU: 96 > src/device.c:gatt_debug() Primary services found: 4 > src/device.c:gatt_debug() start: 0x0001, end: 0x0003, uuid: > 00001800-0000-1000-8000-00805f9b34fb > src/device.c:gatt_debug() start: 0x0007, end: 0x000f, uuid: > 03b80e5a-ede8-4b33-a751-6ce34ec4c700 > src/device.c:gatt_debug() start: 0x0021, end: 0x0023, uuid: > 00001801-0000-1000-8000-00805f9b34fb > src/device.c:gatt_debug() start: 0x0031, end: 0x0041, uuid: > 0000180a-0000-1000-8000-00805f9b34fb > src/device.c:gatt_debug() Characteristics found: 19 > src/device.c:gatt_debug() start: 0x0002, end: 0x0007, value: 0x0003, > props: 0x0a, uuid: 00002a00-0000-1 > src/device.c:gatt_debug() start: 0x0008, end: 0x28a5, value: 0x0009, > props: 0x18, uuid: 00000318-0000-1 > src/device.c:gatt_debug() start: 0x28a6, end: 0xa347, value: 0xecd8, > props: 0x5e, uuid: 00001c91-0000-1 > src/device.c:gatt_debug() start: 0xa348, end: 0x000a, value: 0x5343, > props: 0xac, uuid: 00004953-0000-1 > src/device.c:gatt_debug() start: 0x000b, end: 0x9d0f, value: 0x000c, > props: 0x1e, uuid: 00006bf3-0000-1 > src/device.c:gatt_debug() start: 0x9d10, end: 0x6840, value: 0xa9f2, > props: 0x66, uuid: 000012a1-0000-1 > ... > > From parsing handle 8, he parses 3 16 bit UUIDs instead of one 128bit. > > wireshark has the same problem and misparses the buffer. > > The buffer is the result of a > ATT_OP_READ_BY_TYPE_RESP opcode, which contains a unit length for the > whole buffer, which is correct for some, but no all characteristics in > the PDU. > > Comparing the attributs from my working with my not working device, I find: > - The not working ROLAND has a total of 3 characteristics with 128bit > UUIDS for the MIDI Service, the one needed ist the second one. > - The device also contains an audio sink, which I think does not matter > > Now for the things that I don't know and where I could use some help: > - Bug in the bluez stack or should I write to Roland? > - I have no idea why my other MIDI Device works, mixed 16bit and > 128bit UUIDS is needed in both cases > - How can I make sure that an attribute response only contains UUIDs > of one kind? That seems to be required, since there is only one 'len' > element. > - Any tips on what needs to be changed? Well if the device is returning mixed UUID sizes then there is nothing we can do to figure out since as you said there is only one len so all elements should be of the same length, perhaps Android doesn't use Read By Type procedure and discover them, anyway it is perhaps worth notifying them about this problem given that it doesn't seem to conform to the spec. > Also attached is a wireshark dissection and hexdump of the "Read by Type > Response": > > I have a very ugly workaround, but having spent way to much time on > debugging this, I could also invest the work for a proper patch. > > Thanks, > Jo > -- > Johannes Deisenhofer -- Luiz Augusto von Dentz
