Hi arman,
> You can start playing with the code by using tools/btgatt-client, which got merged
> into the tree over the weekend. This basically demonstrates how the tools &
> daemon can interact with shared/gatt-client. Also take a look at shared/att,
> shared/gatt-helpers, and shared/gatt-client where the new code is implemented.
I take some time delved in shared/* files, although I cannot take a look at code line
one by one in short time,, the whole stack appear clear to me help work on this.
When I use the btgatt-client tool to connect LE device today, I get a problem as belows:
./btgatt-client -i hci0 -d DA:3E:9D:65:75:BE
Connecting to device ... Failed to connect: Operation now in progress.
I used bluetoothctrl to connect the LE device , it's ok.
I compared btgatt-client l2cap connect process to setup socket parameter with bluetoothd
did, the process of setting socket configuration seems to be the same.
What details did I forget to do to result in this problem? Did you encounter on this issue?
> One of the TODOs you can initially look at is supporting signed writes using
> shared/att. Given the necessary keys, we want struct bt_att to automatically sign
> outgoing PDUs (for client) and verify the signature of incoming PDUs (for server)
> when the "signed" bit of the opcode is set to 1. There was an email conversation
> some time ago on how to access the keys; feel free to dig that up and see what you
> can come up with.
Maybe the mail title does not include "signed write" key word, can you tell me about
which month in that discussion came out ?
> The TODO items marked as C1/C2 are fairly straightforward to implement. The
> others require some discussion/API design. I think the most complex task will be to
> migrate the daemon code from GAttrib to shared/gatt-client, since a lot of the
> plugins use that code. We'll likely need a new plugin probing interface for GATT, as
> the plugins won't perform service discovery any more.
>
I agree that there are too many dependency on GArrtib now, it's a difficult migration
work. You said probing interface for GATT that is not very clear to me. For my understanding,
although plugin won't perform service discovery any more, they can tranverse the service_list
in the bt_gatt_client structure. So for plugins, they only need the bt_gatt_client structure
created once device connected.
> The main thing that makes this part difficult is that GAttrib and bt_att cannot
> operate on the same socket fd, since they will likely break the sequential protocol
> requirements of ATT, so the plugins can't be easily converted one at a time. We may
> need a deprecation strategy for this (e.g. perhaps initially have a
> shared/att-gattrib.c of sorts, that internally uses the GAttrib from device.c and then
> we switch to the struct io based one once all plugins have been converted), or
> perhaps we just convert it all at once in one swooping patch set. Either way, some
> discussion is needed on this (perhaps in a separate email thread).
>
> I hope this helps!
> Arman
Thanks
Chaojie Gu
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
