MCAP requires that connections are refused at L2CAP layer using a
connection response "Connection refused -no resources available".
By default, deferred connections in BlueZ are rejected using the
code "Connection refused - security block".
As in BlueZ is not possible to reject the defer connection with
this response code. This patch don't defer the connection and
close it immediately. This is also a valid behaviour for rejecting
connections in MCAP.
For descriptors, a comment is added explaining why UUID 128-bit support
is not necessary yet. For characteristic discovery, characteristics with
128-bit UUID types are now loaded.
This primary service contains 128-bit UUIDs on the service declaration
and characteristic declaration attributes, useful to test the 128-bit
UUID support.
Besides registering the characteristics when we receive the Attribute
Not Found Error, we should also register the characteristics when we
get to the end of the handle range contained in that service.
According to the definition of ending of a service[1], the service
must end at the next service declaration, that includes a Secondary
Service.
There's one issue that I did not find a definitive answer in the spec,
in the case that the end handle of the request is less than the End
Group handle of the service, what should be put in the response?
[1] "The service definition ends before the next service declaration
or after the maximum Attribute Handle is reached."
When using the minimum MTU, in some cases, mostly when using 128-bit UUIDs,
the PDU is exactly the size of the minimum MTU. In those case there were
off-by-one errors. Errors are returned if can't put anything useful inside
the requested PDU.
In the case that there wasn't any service in the requested range,
we should include the beginning of the range, in the Attribute
Not Found Error Response.
In some cases, there could be a file descriptor leak, when the
connection is not succesful. As the connection callback keeps a
reference, there's no problem unref'ing it at this point.
Stream should only be closed if sep is unlocked otherwise there is a
possibility that sep reconfiguration is triggered although the sep is in
use by the user application.
