Valid Range descriptor contains two unsigned 16-bits integers
representing the valid range of values that the Measurement Interval
characteristic can support.
This patch avoids invalid memory access when decoding ATT read response
PDUs. The ATT_MTU value is a per ATT Bearer value defined by the higher
layer specification.
Commit "aa3b9016bf444b60e1b7e1804dfc323a23a93c5a Convert GDBus methods
to use macro helpers" converted the previous tables to use the new
macros but some flags were lost.
This can leave dangling pointers in case one of the channel is never
connected which cause -EALREADY to be returned by
input_device_set_channel next time the device attempts to connect.
For the same reason the code path when acting as client now add the
watch as soon as the connection completes instead when both channels
are connected.
Due to scheduling/timing on some kernels it is possible that the device
connected event through mgmt comes slightly after an L2CAP socket
receives the same event. We should try to fix this on the kernel side
but as this check in user space is not protecting against critical
errors but just potential profile bugs it can be changed to a simple
warning message.
input() in python < 3.0 is the same as eval(raw_input()) which is not
what we want. With python >= 3.0 in turn raw_input doesn't exist. This
patch fixes support for both versions by a simple try-except clause.
Some devices like Sony Ericsson MW600 reject AVDTP_START if it was the
initiator of the connection, apparently it follows recommendation 12 of
simultaneous use of HFP, A2DP and AVRCP profiles white paper which says:
"If the RD has configured and opened a stream it is also responsible to
start the streaming via GAVDP_START."
If the client is fast enough and try to acquire the transport this cause
an error, so instead of sending AVDTP_START the code now checks if it is
the acceptor of the stream and wait the remote side to send the command.
When accepting the suspend indication all callbacks should be notified
that suspend completed.
In addition to this fix not using avdtp_start return in indication
callback as well as in the confirmation.
Check collision for AVDTP Open, Close, Start, Suspend and Abort commands
and if they collided remove the pending request if SEP has accepted the
indication.
This patch makes the python tests source-compatible with python 3, while
leaving the interpreter at python 2 for now.
The tradeoff is that this source is no longer compatible with python
versions < 2.6, and requires gobject-introspection for the glib-based
tests.
MGMT_OP_ADD_UUID may fail with EBUSY due to ongoing CoD update. In case
of EBUSY error wait for Class Of Device changed event before adding
more UUIDs.
The attrib server code relies on these id's to be unique globally and
not just per GAttrib instance. As an easy fix make them global by adding
a static guint to g_attrib_register.
The callbacks could result with the reference count dropping to 0 and
the object being freed. This patch fixes the issue by adding one extra
reference for the duration of the timeout function.
If the client requests an ATT_MTU less than the minimum ATT_MTU,
the server should send an Error Response message with Request Not
Supported code.
According to GATT spec, the server shall respond to Exchange MTU
Requests messages with an Exchange MTU Response with the Server
Rx MTU parameter set to the maximum MTU that this server can
receive. Thus, we should get L2CAP imtu value in order to properly
send the Exchange MTU Response message.
Additionally, we should not change the L2CAP ATT fixed channel MTU.
bt_io_set call will always fail since we are not supposed to change
L2CAP MTU after connection is established.
In attrib_channel_attach, channel->mtu should be initialized according
to ATT_MTU value.
Over BR/EDR, ATT_MTU should be set to the L2CAP imtu negotiated during
L2CAP configuration phase. Over LE, ATT_MTU should be 23 octets.
23 octets is the default (and minimum) ATT_MTU value. If someone tries
to set ATT_MTU less than 23 octets g_attrib_set_mtu should fail (return
FALSE). Additionally, there is no constraint regarding the maximum value
of ATT_MTU, so we should not check for it.
Also, we should not change the L2CAP ATT fixed channel MTU. bt_io_set
call will always fail since we are not supposed to change L2CAP MTU
after connection is established.
GAttrib buffer should be allocated according to ATT_MTU value. Over
BR/EDR, ATT_MTU should be set to the L2CAP imtu negotiated during
L2CAP configuration phase. Over LE, ATT_MTU should be 23 octets.
A timer is set when a response is expected. The timer is removed when
data is received, regardless of whether or not the data is a response.
As a result, the timer may be cleared even though a response was not
received and there would be no way to detect a command timeout.
Fix this by clearing the timer only after verifying a response was
received.
Application error codes start off with 0x80 onwards. In CSSv2 the range
0xE0-0xFF is reserved for "Common Profile Error Codes" so we should
ensure not to mix that with our own definitions.
If we get an insufficient encryption error for ATT it doesn't
necessarily mean that we need to have high secirity. If we have an
unauthenticated key and are unencrypted it could also mean that we just
need to encrypt the link (medium security). Always requiring high
security would make the connection fail for unauthenticated keys.
