My Lua BLE dissector is not called for a GATT Read Blob Response
I am implementing a set of Lua dissectors in order to dissect a proprietary BLE GATT based protocol.
One of the BLE characteristics to read is too long to fit in a standard HCI frame. The protocol does not use the HCI ACL "Reassemble ACL fragments" option, but does
- A GATT Read Request that returns the first 22 bytes
- A GATT Read Blob request for the remaining 10 bytes at offset 22
If have a lua dissector p_nexxt_ccdtr to handle these 2 messages and assemble them. It is registered as
local bt_dissector = DissectorTable.get("bluetooth.uuid")
bt_dissector:add(<proprietary 128 bit UUID>", p_nexxt_ccdtr)
This dissector is correctly triggered by the Read response, but not the Read Blob response. Wireshark shows for both response messages the same information on the ATT protocol layer, including the correct UUIDs.
I see in packet-btatt.c:dissect_btatt() that the opcodes 0x0b (Read Response) and 0x0d (Read Blob Response) are treated differently, but could not figure out what is going on.
Why is my "bluetooth.uuid" dissector hit for a Read response, but not a Read Blob response?
10524: Bluetooth Smart: Add GATT dissector has a sample capture attached (
HR_SENSOR_btsnoop_hci.log).There is one packet (
747) with opcode 0x0d. Does your dissector behave differently with this capture?Notes: opcode check added in 68a7add6 to fix 16258: [oss-fuzz] Null-dereference READ in dissect_btatt
Hello Chuckc,
The scenario in HR_SENSOR_btsnoop_hci.log is the same as what I have. The only difference is that I have a 128-bit UUID instead of a 16-bit one.
HR_SENSOR_btsnoop_hci.log reads the contents of the characteristic with handle 0x2A (0x2a28: Device Information: Software Revision String) which is apparently 27 bytes long. The Sent Read Request in packet 728 returns a response of 22 value bytes in packet 736. Packet 736 gives an Expert Info that the attribute value is probably longer. The Sent Read Blob Request in packet 737 reads the remaining 5 bytes at offset 22, which are returned in packet 747. For packet 747, Wireshark assembles the two parts and shows a Software Revision String of "Application version 2.4.1.0".
In my log the client reads the contents of a proprietary characteristic with a 128-bit UID, which I defined in my bluetooth_uuids file. Its value ...(more)
I'm not sure if this is a bug or an Enhancement Request.
Can you provide a sample capture and open an issue on Gitlab?
Done. See Support long_attribute_value for proprietary 128-bit UUIDs BTGATT attribute values