| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This allows application to return error codes in the range allowed by
the spec:
'GATT - Section 4.9.5:
Application Error 0x80 – 0x9F Application error code defined by a
higher layer specification.'
|
|
|
|
|
|
| |
Update docs to reflect the addition of the `X-notify` and `X-indicate`
characteristic flags, which allow a GATT server to restrict CCC write
permissions.
|
|
|
|
|
|
|
|
|
| |
This adds MTU properyt to GattCharacteristic1 which can be used in
order to determine how much data can be read/write using non-long
procedures which sometimes is the only thing the remote device
supports.
Fixes: https://github.com/bluez/bluez/issues/199
|
|
|
|
|
| |
When a device is disconnecting, StartNotify is not allowed. This adds a
new error type to the doc.
|
|
|
|
| |
Allows 'extended-propeties' as flags.
|
|
|
|
|
|
|
| |
The option "type" can be used to force a certain procedure to be used:
- "command": Use Write Without Response procedure
- "request": Use (Long) Write With Response procedure
- "reliable"" Use Reliable Write procedure
|
|
|
|
|
|
|
|
|
|
|
|
| |
When acting as server it is useful to select where to allocate the
handle for an attribute so it can be restored in the same position when
restarting the daemon or rebooting the system.
In order to do that the application also needs to know in which handle
the attribute is allocated the very first time it is registered, this
also allows for a better integration with PTS and tools like auto-pts
which needs to know the handles where the attributes have been
allocated.
|
|
|
|
|
| |
Only support sockets with AcquireWrite/AcquireNotify since pipe don't
work with sendmsg therefore MSG_NOSIGNAL cannot be used.
|
|
|
|
| |
Make it clearer what values it can assume and also fit in 80 columns.
|
| |
|
|
|
|
|
|
|
| |
This patch adds authorization property for attributes and prepare write
request for authorization option for write request. This is require to
handle correctly prepare writes, which may response with insufficient
authorization error.
|
|
|
|
|
| |
This reflects what the code has already doing so any server operation which
requires the device option shall also get the link type as well.
|
|
|
|
| |
It is perfectly fine to have a service without any Includes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds handling of invalid offset error for gatt database in
case if offset in read blob would be invalid.
"The Read Blob Request is repeated until the Read Blob Response’s Part
Attribute Value parameter is zero or an Error Response is sent by the server
with the Error Code set to Invalid Offset." Bluetooth Core 5.0, 4.12.2
"If the prepare Value Offset is greater than the current length of the attribute
value then all pending prepare write values shall be discarded for this client,
the queue shall be cleared and then an Error Response shall be sent with the
«Invalid Offset»." Bluetooth Core 5.0, 3.4.6.3
|
|
|
|
| |
included service support implemented at server side
|
|
|
|
| |
AcquireWrite and AcquireNofify are required by meshctl.
|
|
|
|
|
| |
This adds link option to ReadValue and WriteValue so the application
can determine which bearer the request is coming from.
|
|
|
|
|
|
|
|
|
| |
This enables servers to use the same mechanism to use packet based IO
using file descriptors bypassing D-Bus.
Note that the application is free to choose any type of medium that can
use file descriptors, thus this is not limited to pipe2 although that is
probably recommended due its simplicity.
|
|
|
|
|
| |
Add Confirm method which doesn't expect a reply so it is just
confirmation that value was received.
|
|
|
|
|
|
|
|
| |
This adds release-notify command which closes an existing fd unlocking
the attribute:
[Test peripheral:/service001f/char0020]# release-notify
[CHG] Attribute /org/bluez/hci1/dev_69_16_5B_9A_06_CD/service001f/char0020 NotifyAcquired: no
|
|
|
|
|
|
| |
This enables write and notify exclusive access via file descriptors in
case the characteristic is actually trying to emulate a byte stream
transfer or have a protocol on top of GATT.
|
|
|
|
| |
Correct small spelling errors
|
| |
|
|
|
|
|
| |
These interfaces have been in use for quite a while in chromium where it
is used by Web Bluetooth APIs.
|
|
|
|
|
| |
This add secure-{read,write} which shall be used by servers that want
to restrict attribute access to secure connection only (BT_SECURITY_FIPS)
|
|
|
|
|
|
| |
Since RegisterApplication makes use of ObjectManager it is also possible
to verify the existance of GattProfile objects unifying the API for both
services (GATT server) and profiles (GATT client).
|
|
|
|
|
| |
This adds the possibility to pass an offset to these operations, and
also in the server case to give the device object.
|
|
|
|
|
| |
If the characteristic does not support nofications nor indications the
Notifying property can be omitted as it will never going to be used.
|
|
|
|
|
| |
These properties are no longer needed since the objects shall be managed
with use of ObjectManager both in case of client and server.
|
|
|
|
|
|
|
|
|
| |
ObjectManager path shall not contain other intefaces in its root path, only
child objects shall be included with many bindings following this.
Due to this limitation and also the fact that application might actually
have a single ObjectManager path so all services can be registered at
once.
|
|
|
|
|
| |
This adds Flags property to GattDescriptor so the server can define
permissions and authentication requirements for descriptors.
|
|
|
|
|
| |
This add encryption flags which can be used when registering a service to
require encryption when accessing a characteristic.
|
|
|
|
|
|
|
| |
After some discussion it was decided to require an ObjectManager
interface implementation on a per-service basis to reduce the
overhead of heaving to process and cache potentially many non-GATT
related objects. This patch updates the documentation to reflect this.
|
|
|
|
|
|
|
|
|
|
|
| |
Until now the GATT D-Bus API doesn't provide any way to register client
role profiles so that bluetoothd would be able to add matching devices
to its auto-connect list (managed by the kernel from 3.17 onward). To
keep the GATT D-Bus interface as capable as the internal plugin API this
patch adds a new concept of a GattProfile1 D-Bus object. By registering
such an object and providing a set of mandatory service UUIDs bluetoothd
will start performing matching against remote devices and add them to
the auto-connect list.
|
| |
|
|
|
|
|
|
| |
Updated possible error names that can be returned from
ReadValue/WriteValue methods to match those currently returned from the
experimental implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces the following new properties to the GattService1
interface:
Device: A remote-service-only property that contains the D-Bus object
path of the associated device.
Primary: Reflects whether or not a services is primary or secondary.
This patch also introduces new methods to GattCharacteristic1 and
GattDescriptor1 for reading and writing the corresponding attribute
values and a new signal for being notified of received notifications and
indications.
The "Value" D-Bus property is removed from both interfaces
and replaced with asynchronous ReadValue and WriteValue functions. This
is due to the fact that DBus.Properties.Get is synchronous and without
an asynchronous way of issuing a GATT value read request, there are
cases where a single read and cache based approach becomes limiting
(e.g. when a characteristic allows reads but no notifications) and
relying on the PropertyChanged signal to retrieve the value of a read
request asynchonously as well as to signal notifications/indications
makes for a vague API.
|
|
|
|
|
| |
This patch adds "org.bluez.Error.InvalidArguments" as possible error
returned by GattManager1.UnregisterService().
|
| |
|
|
|
|
|
| |
Remove Core SPEC page number from the API document to avoid wrong
page reference when the SPEC changes.
|
|
This patch proposes an unified GATT API for local and remote services.
|