Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I spent a good part of a year working specifically with the Bluetooth GATT spec designing my own client and servers which would try to function as close to the spec as possible.

The spec is very bad, I'm sorry but I understand the amount of effort that must have gone into building it. There are blatant holes in the entire spec, documents are broken apart in some chaotic pattern where to implement a single ATT you need to reference 3 documents simultaneously(almost).

The documents have broken links or just flat out incorrect links. Worst part is, a lot of device manufacturers just yeet the GATT out the window and have custom UUIDs with custom everything which you'll never be able to implement properly with reverse engineering it.

Idk I think the spec is a good initiative marred by execution



> Worst part is, a lot of device manufacturers just yeet the GATT out the window and have custom UUIDs with custom everything which you'll never be able to implement properly with reverse engineering it.

Sorry, I’m part of the problem. ^_^; If you read the BLE Developers Handbook, it paints a beautiful picture of a mesh of low power sensor devices that periodically advertise information, and it helped put the design of GATT into context for me. Of course, we had no interest in using GATT in that manner - we just wanted the other features of BLE. One fundamental issue is that if you want E2E transport encryption to a specific mobile app, LE bonding is no longer sufficient. So you start rolling your own crypto only to realize that negotiated MTU means your max datagram size is variable and dynamic. From there, you’re well on your way to implementing a custom transport layer on top of GATT. If you don’t horribly abuse GATT and use it for its intended purpose (like some of the standardized profiles on top of GATT), it works fairly decently.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: