| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This is now handled by checking if the command collided.
|
|
|
|
|
| |
Change return of avdtp_start to -EINPROGRESS so the caller can check if
the operation is in progress and don't abort because of that.
|
|
|
|
| |
ABORT command cannot be rejected
|
|
|
|
|
|
|
| |
AVDTP spec, 8.15.2 Abort Response:
"If an AVDTP_ABORT_CMD contains an invalid SEID, no response shall be
sent."
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 an abort is received all setup callbacks should return an error.
|
|
|
|
|
| |
Only process callbacks if avdtp_start was sent, otherwise it may cancel
setup callbacks that were registere via g_idle_add.
|
|
|
|
|
| |
When accepting the open indication all config callbacks should be
notified that open completed.
|
|
|
|
|
|
|
|
| |
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 is a plugin, so spell -avoid-version correctly so
it doesn't have a full soname.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This script is back from BlueZ 3.x times and unusable now
|
|
|
|
| |
Seeing as we want to install it.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Don't print error message for actions that are expected or recoverable
i.e. add_uuid returning EBUSY status.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Break loop when pending command was found and callback called.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This workaround is not necessary anymore since setsockopt is now
checking for minimum MTU.
|
|
|
|
|
|
| |
Use BT_IO_OPT_IMTU instead of BT_IO_OPT_OMTU in bt_io_connect.
We cannot control omtu value since it is negotiated during L2CAP
configuration phase.
|
|
|
|
|
| |
There is no need to set the omtu of L2CAP ATT fixed channel. We
use the default value.
|
|
|
|
| |
We should update the GAttrib buffer length after exchanging ATT_MTU.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|