This patch updates the L2CAP Channel state to Connected when LE Link
is established, so that data transmission can start on CID 4.
Without this fix if remote side sends data on CID 4 immidiately after
LE Link was established, data was being discarded in l2cap_att_channel()
API because channel state was still BT_CONNECT when SMP pairing is in
progress. This was resulting in disconnection from remote side after 30 seconds
since ATT request was not answered by user space as data was discarded.
Signed-off-by: Hemant Gupta <[email protected]>
---
net/bluetooth/l2cap_core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 15478b3..20dbebb 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1189,6 +1189,7 @@ static void l2cap_conn_ready(struct l2cap_conn *conn)
l2cap_chan_lock(chan);
if (conn->hcon->type == LE_LINK) {
+ __l2cap_state_change(chan, BT_CONNECTED);
if (smp_conn_security(conn, chan->sec_level))
l2cap_chan_ready(chan);
--
1.7.0.4
Hi Gustavo,
On Thu, Apr 19, 2012 at 7:33 PM, Gustavo Padovan <[email protected]> wrote:
> Hi Hemant,
>
> * Hemant Gupta <[email protected]> [2012-04-18 10:24:34 +0530]:
>
>> This patch updates the L2CAP Channel state to Connected when LE Link
>> is established, so that data transmission can start on CID 4.
>> Without this fix if remote side sends data on CID 4 immidiately after
>> LE Link was established, data was being discarded in l2cap_att_channel()
>> API because channel state was still BT_CONNECT when SMP pairing is in
>> progress. This was resulting in disconnection from remote side after 30 seconds
>> since ATT request was not answered by user space as data was discarded.
>
> I'm not too familiar with all LE specifications, but doesn't this initial
> data need to be secured? If the channel is not secure (the pairing has
> not finished yet) and we may be transmitting in a not secure enough place.
Actually for LE, L2CAP has fixed CID's, so data transmission can start
as soon as
LE Link is established. Remote side can send data on CID 4 as soon as
LE Link is created,
even though we might have initiated pairing on SMP channnel 06 which
can continue parallely.
Problem in this case arise, if we receive data from remote side when
we are performing SMP
pairing, so L2CAP state would be BT_CONNECT, and in
l2cap_att_channel() API, we will discard
that packet from remote side, resulting in no response to that
particular packet from remote side.
This could result in disconnection from remote side because ATT
command was not answered
by us for more than 30 seconds..
I will send new version of patch for comments, because I think it is
better to call l2cap_chan_ready(chan)
which will update the state as well has proper locks before updating
the state, which was not the case with the above patch.
> ? ? ? ?Gustavo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Hemant,
* Hemant Gupta <[email protected]> [2012-04-18 10:24:34 +0530]:
> This patch updates the L2CAP Channel state to Connected when LE Link
> is established, so that data transmission can start on CID 4.
> Without this fix if remote side sends data on CID 4 immidiately after
> LE Link was established, data was being discarded in l2cap_att_channel()
> API because channel state was still BT_CONNECT when SMP pairing is in
> progress. This was resulting in disconnection from remote side after 30 seconds
> since ATT request was not answered by user space as data was discarded.
I'm not too familiar with all LE specifications, but doesn't this initial
data need to be secured? If the channel is not secure (the pairing has
not finished yet) and we may be transmitting in a not secure enough place.
Gustavo