Add server mode

[muka]

Expose GATT services via bluez GattManager1

References

• https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt
• https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server

Tasks

• Create an Application wrapper interface
• Create the ObjectManger interface
• Create the Properties interface
• Allow to create Service & Characteristic
• Add Advertising support (Advertisment support #25)
• Add integrated test for client/server communications
• Write docs with examples

[Packetdancer]

While the baseline is in place, there are several limitations:

1. There doesn't seem to be an easy way to actually include service UUIDs in the advertisement packet.
2. There doesn't seem to be an easy way to actually override the ReadValue/WriteValue behavior in order to provide values.
3. The notification behavior doesn't presently work.

If these three points are addressed, the service mode should work properly.

[muka]

Based on your PR I would say that 2 is done. Do you have any suggestion on the other points ?

1. Maybe can be enabled via an hci command or related to Advertisment support #25?
2. Will check it, probably a communication issue on go-bluetooth side..

Thanks!

[Packetdancer]

2 and 3 are done in the PR, actually; if you use UpdateValue it properly does notification now.

1 can be fixed by #25, yes; adding the UUIDs to ServiceUUIDs would do the trick.

[muka]

Will see to work on #25 soon to close that issue, if you are interested in working on that let me know

[Packetdancer]

I do actually need it for a project, but I'm stuck in client meetings right now; if you haven't gotten to it later this week I might take a stab at it.

[Packetdancer]

For what it's worth, I managed to get advertisement working entirely over dbus (no need to use the btmgmt command), but I'm not 100% happy with the API I put together while testing; I don't quite think it fits with the rest of the existing API properly.

I can throw what I have your way to look at later if you'd like, though.

[muka]

Yup yup, cross posting here 🥇

Please share, I have no particular need to keep that API approach and can eventually forsee a v2

In the meanwhile, I added an inital implementation and next step is probably to be bind at the service initialization

[Packetdancer]

Awesome! My implementation had it as part of Application; when you initialized a service I had a new 'Advertised' field in the config struct, and then Application had a StartAdvertising where it would build an LEAdvertisement1 based on the app.config.name (for LocalName) and what services were flagged as Advertised, and register the advertisement.

[muka]

Great, let me check the implementation. Mine is in https://github.com/muka/go-bluetooth/tree/dev

[Packetdancer]

Mine's in https://github.com/packetdancer/go-bluetooth/tree/service-advertisement — feel free to grab whatever helps from there. :)

[Packetdancer]

Only caveat in mine is that after you've called StartAdvertising on the application, you want to grab an Adapter1 and set the Discoverable and Powered properties to true.

The Application implementation of StartAdvertising also needs the Call functionality pulled over into api.* most likely, if my approach was followed.

[Packetdancer]

I also discovered that including the entire advertisement packet doesn't always advertise correctly if not everything was filled out; including just Type, ServiceUUIDs, and LocalName worked properly.

[muka]

Your code looks good to me, would you like to PR?

Thanks!

[Packetdancer]

Let me pull in your implementation and add my features atop it, I think your inclusion of LEAdvertisementManager is a better design in keeping with the framework.

[Packetdancer]

Pull request in!

[muka]

Merged, kudos to @Packetdancer for the great contribution!

Closing #7 and #25. Let's open new ones in case of bugs or further features request