Hi all,
I was pulling my hair on opp a file to a Blackberry. Blackerry is set to "receive using bluetooth".
1. If the Blackberry was not paired before. It ran through ok: enter the pin, accept connection, accept the file.
2. If the Blackberry was paired and in it's device properties, I change the encryption off for my box. It ran through ok, accept connection, accept the file...
3. If the Blackberry was paired and I leave the device properties unchange (default is encryption on). It will fail, not seeing any prompt to accept the connection.
In hcidump I seem to see a problem in #3. After the Encrypt Change there seem to be 2 >con. req. psm 1 scid 0x0040
Any suggestion on how to trace it down/work around this?
.............
> HCI Event: Read Remote
Supported Features (0x0b) plen 11
< ACL data: handle 42 flags
0x02 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Number of
Completed Packets (0x13) plen 5
> HCI Event: Encrypt Change
(0x08) plen 4
< ACL data: handle 42 flags
0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
> ACL data: handle 42 flags
0x02 dlen 12
L2CAP(s): Info rsp: type 2 result 1
Not supported
< ACL data: handle 42 flags
0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
> HCI Event: Number of
Completed Packets (0x13) plen 5
> HCI Event: Number of
Completed Packets (0x13) plen 5
> ACL data: handle 42 flags
0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid
0x0040 result 0 status 0
Connection successful
< ACL data: handle 42 flags
0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags
0x00 clen 0
> ACL data: handle 42 flags
0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid
0x0040 result 4 status 0
Connection refused - no resources
available
.................
Regards, Ed
__________________________________________________________________
Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/
Marcel,=0A=0A>> It is a ubutunu distribution. 2.6.31-17-generic.=0A>can you=
test with a 2.6.33-rc6 vanilla kernel. I really thing this got=0A>fixed an=
d you might see a side effect or bad patch here.=0A=0AI think you are absol=
ute right. This look like the Bluetooth:L2CAP... patch that Liejun is worki=
ng on.=0AI am just too new to linux, need to learn how to compile and insta=
ll the kernel first.=0AIf it does not work out on 2.6.33, then I will come =
back with more info.=0AIn the mean time: hcidump -X -V (hope a bit more in=
fo to confirm the same issue).=0A------------------------------------------=
---------------------=0A> HCI Event: Connect Complete (0x03) plen 11=0A =
status 0x00 handle 42 bdaddr 00:1C:CC:23:8F:68 type ACL encrypt 0x00=0A< HC=
I Command: Read Remote Supported Features (0x01|0x001b) plen 2=0A handle=
42=0A> HCI Event: Command Status (0x0f) plen 4=0A Read Remote Supported=
Features (0x01|0x001b) status 0x00 ncmd 0=0A> HCI Event: Page Scan Repetit=
ion Mode Change (0x20) plen 7=0A bdaddr 00:1C:CC:23:8F:68 mode 1=0A> HCI=
Event: Max Slots Change (0x1b) plen 3=0A handle 42 slots 5=0A> HCI Even=
t: Command Status (0x0f) plen 4=0A Unknown (0x00|0x0000) status 0x00 ncm=
d 1=0A> HCI Event: Read Remote Supported Features (0x0b) plen 11=0A stat=
us 0x00 handle 42=0A Features: 0xbf 0xfe 0x8f 0xfe 0x98 0x19 0x00 0x80=
=0A< ACL data: handle 42 flags 0x02 dlen 10=0A L2CAP(s): Info req: type =
2 (***)=0A> HCI Event: Encrypt Change (0x08) plen =
4 (***)=0A status 0x00 handle 42 encrypt 0x01=0A< ACL data: handle 4=
2 flags 0x02 dlen 12=0A L2CAP(s): Connect req: psm 1 scid 0x0040 (**=
**)=0A> HCI Event: Number of Completed Packets (0x13) plen 5=0A handle 4=
2 packets 1=0A> HCI Event: Number of Completed Packets (0x13) plen 5=0A =
handle 42 packets 1=0A> ACL data: handle 42 flags 0x02 dlen 12=0A L2CAP(=
s): Info rsp: type 2 result 1=0A Not supported=0A< ACL data: handle 42=
flags 0x02 dlen 12=0A L2CAP(s): Connect req: psm 1 scid 0x0040 (****)=
=0A> ACL data: handle 42 flags 0x02 dlen 16=0A L2CAP(s): Connect rsp: dc=
id 0x0040 scid 0x0040 result 0 status 0=0A Connection successful =
(****)=0A< ACL data: handle 42 flags 0x02 dlen 12=
=0A L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0=0A> ACL data: ha=
ndle 42 flags 0x02 dlen 16=0A L2CAP(s): Config req: dcid 0x0040 flags 0x=
00 clen 4=0A MTU 1024=0A< ACL data: handle 42 flags 0x02 dlen 18=0A =
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4=0A MTU 1=
024=0A> HCI Event: Number of Completed Packets (0x13) plen 5=0A handle 4=
2 packets 1=0A> HCI Event: Number of Completed Packets (0x13) plen 5=0A =
handle 42 packets 1=0A> HCI Event: Number of Completed Packets (0x13) plen =
5=0A handle 42 packets 1=0A> ACL data: handle 42 flags 0x02 dlen 16=0A =
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0040 result 4 status 0=0A =
Connection refused - no resources available (***)=0A> ACL data: hand=
le 42 flags 0x02 dlen 14=0A L2CAP(s): Config rsp: scid 0x0040 flags 0x00=
result 0 clen 0=0A Success=0A< HCI Command: Remote Name Request (0x01=
|0x0019) plen 10=0A bdaddr 00:1C:CC:23:8F:68 mode 2 clkoffset 0x0000=0A>=
HCI Event: Command Status (0x0f) plen 4=0A Remote Name Request (0x01|0x=
0019) status 0x00 ncmd 1=0A> HCI Event: Remote Name Req Complete (0x07) ple=
n 255=0A status 0x00 bdaddr 00:1C:CC:23:8F:68 name 'bb 8300e'=0A< HCI Co=
mmand: Disconnect (0x01|0x0006) plen 3=0A handle 42 reason 0x13=0A Re=
ason: Remote User Terminated Connection=0A---------------------------------=
-----------------------------=0ARegards, Ed=0A=0A=0A _________________=
_________________________________________________=0AThe new Internet Explor=
er=AE 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free=
! at http://downloads.yahoo.com/ca/internetexplorer/
Hi Ed,
> >> In hcidump I seem to see a problem in #3. After the Encrypt Change there seem to be 2 >con. req. psm 1 scid 0x0040
>
> >what kernel version is this? I think we fixed that already.
> It is a ubutunu distribution. 2.6.31-17-generic.
can you test with a 2.6.33-rc6 vanilla kernel. I really thing this got
fixed and you might see a side effect or bad patch here.
Regards
Marcel
Hi Marcel,
>> In hcidump I seem to see a problem in #3. After the Encrypt Change there seem to be 2 >con. req. psm 1 scid 0x0040
>what kernel version is this? I think we fixed that already.
It is a ubutunu distribution. 2.6.31-17-generic.
Ed
__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
http://ca.toolbar.yahoo.com.
Hi Ed,
> I was pulling my hair on opp a file to a Blackberry. Blackerry is set to "receive using bluetooth".
> 1. If the Blackberry was not paired before. It ran through ok: enter the pin, accept connection, accept the file.
> 2. If the Blackberry was paired and in it's device properties, I change the encryption off for my box. It ran through ok, accept connection, accept the file...
> 3. If the Blackberry was paired and I leave the device properties unchange (default is encryption on). It will fail, not seeing any prompt to accept the connection.
>
> In hcidump I seem to see a problem in #3. After the Encrypt Change there seem to be 2 >con. req. psm 1 scid 0x0040
what kernel version is this? I think we fixed that already.
Regards
Marcel
Hi,
On Tue, Feb 2, 2010 at 2:33 PM, Ed Tsang <[email protected]> wrote:
>
> Hi all,
> ?I was pulling my hair on opp a file to a Blackberry. Blackerry is set to "receive using bluetooth".
> 1. If the Blackberry was not paired before. It ran through ok: enter the pin, accept connection, accept the file.
> 2. If the Blackberry was paired and in it's device properties, I change the encryption off for my box. It ran through ok, accept connection, accept the file...
> 3. If the Blackberry was paired and I leave the device properties unchange (default is encryption on). It will fail, not seeing any prompt to accept the connection.
>
> In hcidump I seem to see a problem in #3. After the Encrypt Change there seem to be 2 >con. req. psm 1 scid 0x0040
>
> Any suggestion on how to trace it down/work around this?
> .............
>
> > HCI Event: Read Remote
> Supported Features (0x0b) plen 11
> < ACL data: handle 42 flags
> 0x02 dlen 10
> ? ?L2CAP(s): Info req: type 2
> > HCI Event: Number of
> Completed Packets (0x13) plen 5
> > HCI Event: Encrypt Change
> (0x08) plen 4
> < ACL data: handle 42 flags
> 0x02 dlen 12
> ? ?L2CAP(s): Connect req: psm 1 scid 0x0040
> > ACL data: handle 42 flags
> 0x02 dlen 12
> ? ?L2CAP(s): Info rsp: type 2 result 1
> ? ? ?Not supported
> < ACL data: handle 42 flags
> 0x02 dlen 12
> ? ?L2CAP(s): Connect req: psm 1 scid 0x0040
> > HCI Event: Number of
> Completed Packets (0x13) plen 5
> > HCI Event: Number of
> Completed Packets (0x13) plen 5
> > ACL data: handle 42 flags
> 0x02 dlen 16
> ? ?L2CAP(s): Connect rsp: dcid 0x0040 scid
> 0x0040 result 0 status 0
> ? ? ?Connection successful
> < ACL data: handle 42 flags
> 0x02 dlen 12
> ? ?L2CAP(s): Config req: dcid 0x0040 flags
> 0x00 clen 0
> > ACL data: handle 42 flags
> 0x02 dlen 16
> ? ?L2CAP(s): Connect rsp: dcid 0x0041 scid
> 0x0040 result 4 status 0
> ? ? ?Connection refused - no resources
> available
> .................
> Regards, Ed
>
>
>
> ? ? ?__________________________________________________________________
> Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/
> --
> 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
I'm trying to resolve this issue. Let me post the patch for review.
On Wed, Jun 16, 2010 at 4:39 PM, Ed Tsang <[email protected]> wrote:
> Anrel, =A0what kernel version are you using?
> Previously it was happening with a Blackberry on 2.6.31-17. I was plannin=
g to dig into it, then I upgraded my ubuntu with (2.6.32-22) and the proble=
m disappeared. I am guessing it might be a raising condition with certain p=
hone during certain circumstance. I think Liejun Tao <[email protected]=
m> has investigate this one too.
I guess that new kernel have different timing. This condition is not
easy to get as several packets have milliseconds between each other
...
We are using kernel 2.6.32-xx and it is a bit different since several
patches which fixes kernel crashes are not yet in bluez ...
Regards,
Andrei Emeltchenko
MeeGo Devices
>
> Cheers,
> Ed
>
>
>
> ----- Original Message ----
> From: Andrei Emeltchenko <[email protected]>
> To: Marcel Holtmann <[email protected]>
> Cc: Ed Tsang <[email protected]>; Bluettooth Linux <linux-bluetooth@=
vger.kernel.org>
> Sent: Wed, June 16, 2010 6:21:55 AM
> Subject: Re: double Connect req: psm 1 scid 0x0040 ?
>
> Hi,
>
> On Wed, Feb 3, 2010 at 6:07 PM, Marcel Holtmann <[email protected]> wro=
te:
>>> >> In hcidump I seem to see a problem in #3. After the Encrypt Change t=
here seem to be 2 >con. req. psm 1 scid 0x0040
>>>
>>> >what kernel version is this? I think we fixed that already.
>>> It is a ubutunu distribution. 2.6.31-17-generic.
>>
>> can you test with a 2.6.33-rc6 vanilla kernel. I really thing this got
>> fixed and you might see a side effect or bad patch here.
>
> Marcel we are seeing "double L2CAP connect also" when connecting to
> some smartphones using contran profile. What about following patch
> proposal:
>
> The idea is to use existing flag L2CAP_CONF_CONNECT_PEND to mark that
> L2CAP request has been sent.
>
> Currently it is durty hack, I will send modified patch later today.
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index fc81acb..27bff6e 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -394,6 +394,12 @@ static void l2cap_do_start(struct sock *sk)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0l2cap_pi(sk)->ident =3D l2=
cap_get_ident(conn);
>
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (l2cap_pi(sk)->conf_stat=
e &
> L2CAP_CONF_CONNECT_PEND) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN=
_ERR "\n!!! %s: Connection
> pending !!!\n", __FUNCTION__);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 l2cap_pi(sk)->conf_state |=
=3D L2CAP_CONF_CONNECT_PEND;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0l2cap_send_cmd(conn, l2cap=
_pi(sk)->ident,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0L2CAP_CONN_REQ, sizeof(req), &req);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> @@ -448,6 +454,13 @@ static void l2cap_conn_start(struct l2cap_conn *conn=
)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0l2cap_pi(s=
k)->ident =3D l2cap_get_ident(conn);
>
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (l2cap_p=
i(sk)->conf_state &
> L2CAP_CONF_CONNECT_PEND) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 printk(KERN_ERR "\n!!! %s:
> Connection pending !!!\n", __FUNCTION__);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 bh_unlock_sock(sk);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 continue;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 l2cap_pi(sk=
)->conf_state |=3D
> L2CAP_CONF_CONNECT_PEND;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0l2cap_send=
_cmd(conn, l2cap_pi(sk)->ident,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0L2CAP_CONN_REQ, sizeof(req), &req);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> @@ -3809,6 +3822,7 @@ static int l2cap_security_cfm(struct hci_conn
> *hcon, u8 status, u8 encrypt)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bh_lock_sock(sk);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (l2cap_pi(sk)->conf_state & L2CAP_CONF_=
CONNECT_PEND) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_ERR "\n!!! %s: =
Connection pending
> !!!\n", __FUNCTION__);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bh_unlock_sock(sk);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> @@ -3828,6 +3842,7 @@ static int l2cap_security_cfm(struct hci_conn
> *hcon, u8 status, u8 encrypt)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0l2cap_pi(s=
k)->ident =3D l2cap_get_ident(conn);
>
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 l2cap_pi(sk=
)->conf_state |=3D
> L2CAP_CONF_CONNECT_PEND;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0l2cap_send=
_cmd(conn, l2cap_pi(sk)->ident,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0L2CAP_CONN_REQ, sizeof(req), &req);
>
>
>
>>
>> Regards
>>
>> Marcel
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetoot=
h" in
>> the body of a message to [email protected]
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
>
Anrel, what kernel version are you using?
Previously it was happening with a Blackberry on 2.6.31-17. I was planning to dig into it, then I upgraded my ubuntu with (2.6.32-22) and the problem disappeared. I am guessing it might be a raising condition with certain phone during certain circumstance. I think Liejun Tao <[email protected]> has investigate this one too.
Cheers,
Ed
----- Original Message ----
From: Andrei Emeltchenko <[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: Ed Tsang <[email protected]>; Bluettooth Linux <[email protected]>
Sent: Wed, June 16, 2010 6:21:55 AM
Subject: Re: double Connect req: psm 1 scid 0x0040 ?
Hi,
On Wed, Feb 3, 2010 at 6:07 PM, Marcel Holtmann <[email protected]> wrote:
>> >> In hcidump I seem to see a problem in #3. After the Encrypt Change there seem to be 2 >con. req. psm 1 scid 0x0040
>>
>> >what kernel version is this? I think we fixed that already.
>> It is a ubutunu distribution. 2.6.31-17-generic.
>
> can you test with a 2.6.33-rc6 vanilla kernel. I really thing this got
> fixed and you might see a side effect or bad patch here.
Marcel we are seeing "double L2CAP connect also" when connecting to
some smartphones using contran profile. What about following patch
proposal:
The idea is to use existing flag L2CAP_CONF_CONNECT_PEND to mark that
L2CAP request has been sent.
Currently it is durty hack, I will send modified patch later today.
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index fc81acb..27bff6e 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -394,6 +394,12 @@ static void l2cap_do_start(struct sock *sk)
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ if (l2cap_pi(sk)->conf_state &
L2CAP_CONF_CONNECT_PEND) {
+ printk(KERN_ERR "\n!!! %s: Connection
pending !!!\n", __FUNCTION__);
+ return;
+ }
+
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
}
@@ -448,6 +454,13 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ if (l2cap_pi(sk)->conf_state &
L2CAP_CONF_CONNECT_PEND) {
+ printk(KERN_ERR "\n!!! %s:
Connection pending !!!\n", __FUNCTION__);
+ bh_unlock_sock(sk);
+ continue;
+ }
+
+ l2cap_pi(sk)->conf_state |=
L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
}
@@ -3809,6 +3822,7 @@ static int l2cap_security_cfm(struct hci_conn
*hcon, u8 status, u8 encrypt)
bh_lock_sock(sk);
if (l2cap_pi(sk)->conf_state & L2CAP_CONF_CONNECT_PEND) {
+ printk(KERN_ERR "\n!!! %s: Connection pending
!!!\n", __FUNCTION__);
bh_unlock_sock(sk);
continue;
}
@@ -3828,6 +3842,7 @@ static int l2cap_security_cfm(struct hci_conn
*hcon, u8 status, u8 encrypt)
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ l2cap_pi(sk)->conf_state |=
L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
>
> Regards
>
> Marcel
>
>
> --
> 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
>
Hi,
On Wed, Feb 3, 2010 at 6:07 PM, Marcel Holtmann <[email protected]> wrote=
:
>> >> In hcidump I seem to see a problem in #3. After the Encrypt Change th=
ere seem to be 2 >con. req. psm 1 scid 0x0040
>>
>> >what kernel version is this? I think we fixed that already.
>> It is a ubutunu distribution. 2.6.31-17-generic.
>
> can you test with a 2.6.33-rc6 vanilla kernel. I really thing this got
> fixed and you might see a side effect or bad patch here.
Marcel we are seeing "double L2CAP connect also" when connecting to
some smartphones using contran profile. What about following patch
proposal:
The idea is to use existing flag L2CAP_CONF_CONNECT_PEND to mark that
L2CAP request has been sent.
Currently it is durty hack, I will send modified patch later today.
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index fc81acb..27bff6e 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -394,6 +394,12 @@ static void l2cap_do_start(struct sock *sk)
l2cap_pi(sk)->ident =3D l2cap_get_ident(conn);
+ if (l2cap_pi(sk)->conf_state &
L2CAP_CONF_CONNECT_PEND) {
+ printk(KERN_ERR "\n!!! %s: Connection
pending !!!\n", __FUNCTION__);
+ return;
+ }
+
+ l2cap_pi(sk)->conf_state |=3D L2CAP_CONF_CONNECT_PE=
ND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
}
@@ -448,6 +454,13 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
l2cap_pi(sk)->ident =3D l2cap_get_ident(con=
n);
+ if (l2cap_pi(sk)->conf_state &
L2CAP_CONF_CONNECT_PEND) {
+ printk(KERN_ERR "\n!!! %s:
Connection pending !!!\n", __FUNCTION__);
+ bh_unlock_sock(sk);
+ continue;
+ }
+
+ l2cap_pi(sk)->conf_state |=3D
L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
}
@@ -3809,6 +3822,7 @@ static int l2cap_security_cfm(struct hci_conn
*hcon, u8 status, u8 encrypt)
bh_lock_sock(sk);
if (l2cap_pi(sk)->conf_state & L2CAP_CONF_CONNECT_PEND) {
+ printk(KERN_ERR "\n!!! %s: Connection pending
!!!\n", __FUNCTION__);
bh_unlock_sock(sk);
continue;
}
@@ -3828,6 +3842,7 @@ static int l2cap_security_cfm(struct hci_conn
*hcon, u8 status, u8 encrypt)
l2cap_pi(sk)->ident =3D l2cap_get_ident(con=
n);
+ l2cap_pi(sk)->conf_state |=3D
L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
>
> Regards
>
> Marcel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
" in
> the body of a message to [email protected]
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>