[Bluez-devel] Disconnections are not being detected.

[Bluez-devel] Disconnections are not being detected.

[Vlad]

Greetings,

    I have been struggling with this problem for about a month. However being 
busy with the other projects I did have much time to look closer at this issue
until now.  

    So here is a brief description of the problem: When the client tries to 
make an L2CAP connection to some PSM on the device that doesn't have the server
listen at that PSM, the connection just hangs for a long time (41 sec) and then
eventually times out. Here is a typical log made by 'hcidump', in this case the
server device is a mobile phone  (SonyEriccson T600)  and the client device
is a laptop with D-Link bluetooth dongle (DBT-120). 



1093025240.204350 < HCI Command: Create Connection(0x01|0x0005) plen 13
  4F 7A 7D D9 0A 00 18 CC 01 00 00 00 01 
1093025240.210396 > HCI Event: Command Status(0x0f) plen 4
  00 01 05 04 
1093025241.282201 > HCI Event: Connect Complete(0x03) plen 11
  00 06 00 4F 7A 7D D9 0A 00 01 00 
1093025241.283640 < ACL data: handle 0x0006 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 12 scid 0x0040
1093025241.283651 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4
  06 00 0E 00 
1093025241.287198 > HCI Event: Command Complete(0x0e) plen 6
  01 0D 08 00 06 00 
1093025241.297197 > HCI Event: Number of Completed Packets(0x13) plen 5
  01 06 00 01 00 
1093025241.319200 > ACL data: handle 0x0006 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0000 result 2 status 0
1093025241.320195 < ACL data: handle 0x0006 flags 0x02 dlen 10
    L2CAP(s): Command rej: reason 0
1093025241.332192 > HCI Event: Number of Completed Packets(0x13) plen 5
  01 06 00 01 00 
1093025282.204263 < HCI Command: Disconnect(0x01|0x0006) plen 3
  06 00 13 
1093025282.207737 > HCI Event: Command Status(0x0f) plen 4
  00 01 06 04 
1093025282.285722 > HCI Event: Disconn Complete(0x05) plen 4
  00 06 00 16 



as you see from the log the server device does send back a 'reject' response
but the client device that is running BlueZ stack ignores that response. I
have seen same behavior with the other devices as well ( iPAQs running
familiar linux and PocketPC,  other cell-phones). In all cases the
client device was always a some version of linux with BlueZ.  

Anybody has any clue how to fix this problem or seen similar behavior?

                                                  Vlad


Here is what kernel says about the BlueZ version:

BlueZ Core ver 2.3 Copyright (C) 2000,2001 Qualcomm Inc
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
BlueZ L2CAP ver 2.3 Copyright (C) 2000,2001 Qualcomm Inc
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
BlueZ RFCOMM ver 1.1
Copyright (C) 2002 Maxim Krasnyansky <maxk@qualcomm.com>
Copyright (C) 2002 Marcel Holtmann <marcel@holtmann.org>


And the client device configuration:


hci0:   Type: USB
        BD Address: 00:80:C8:62:F4:C2 ACL MTU: 377:10  SCO MTU: 16:0
        UP RUNNING PSCAN ISCAN 
        RX bytes:775 acl:0 sco:0 events:41 errors:0
        TX bytes:333 acl:0 sco:0 commands:15 errors:0








     




    
 
     



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Disconnections are not being detected.

[Marcel Holtmann]

Hi Vlad,

>     I have been struggling with this problem for about a month. However being 
> busy with the other projects I did have much time to look closer at this issue
> until now.  
> 
>     So here is a brief description of the problem: When the client tries to 
> make an L2CAP connection to some PSM on the device that doesn't have the server
> listen at that PSM, the connection just hangs for a long time (41 sec) and then
> eventually times out. Here is a typical log made by 'hcidump', in this case the
> server device is a mobile phone  (SonyEriccson T600)  and the client device
> is a laptop with D-Link bluetooth dongle (DBT-120). 
> 
> 
> 
> 1093025240.204350 < HCI Command: Create Connection(0x01|0x0005) plen 13
>   4F 7A 7D D9 0A 00 18 CC 01 00 00 00 01 
> 1093025240.210396 > HCI Event: Command Status(0x0f) plen 4
>   00 01 05 04 
> 1093025241.282201 > HCI Event: Connect Complete(0x03) plen 11
>   00 06 00 4F 7A 7D D9 0A 00 01 00 
> 1093025241.283640 < ACL data: handle 0x0006 flags 0x02 dlen 12
>     L2CAP(s): Connect req: psm 12 scid 0x0040
> 1093025241.283651 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4
>   06 00 0E 00 
> 1093025241.287198 > HCI Event: Command Complete(0x0e) plen 6
>   01 0D 08 00 06 00 
> 1093025241.297197 > HCI Event: Number of Completed Packets(0x13) plen 5
>   01 06 00 01 00 
> 1093025241.319200 > ACL data: handle 0x0006 flags 0x02 dlen 16
>     L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0000 result 2 status 0
> 1093025241.320195 < ACL data: handle 0x0006 flags 0x02 dlen 10
>     L2CAP(s): Command rej: reason 0
> 1093025241.332192 > HCI Event: Number of Completed Packets(0x13) plen 5
>   01 06 00 01 00 
> 1093025282.204263 < HCI Command: Disconnect(0x01|0x0006) plen 3
>   06 00 13 
> 1093025282.207737 > HCI Event: Command Status(0x0f) plen 4
>   00 01 06 04 
> 1093025282.285722 > HCI Event: Disconn Complete(0x05) plen 4
>   00 06 00 16 
> 
> 
> 
> as you see from the log the server device does send back a 'reject' response
> but the client device that is running BlueZ stack ignores that response. I
> have seen same behavior with the other devices as well ( iPAQs running
> familiar linux and PocketPC,  other cell-phones). In all cases the
> client device was always a some version of linux with BlueZ.  

actually that is not quite right. The server (phone) sends back a
connect response with PSM not supported error status. And we then send a
command reject for that. This is really stupid. What kernel version do
you use and what kind of hardware is this? Can you reproduce it with the
latest 2.4 or 2.6 kernel?

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Disconnections are not being detected.

[Xavier GARREAU]

>> 1093025241.319200 > ACL data: handle 0x0006 flags 0x02 dlen 16
>>     L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0000 result 2 status 0
>> 1093025241.320195 < ACL data: handle 0x0006 flags 0x02 dlen 10
>>     L2CAP(s): Command rej: reason 0


> actually that is not quite right. The server (phone) sends back a
> connect response with PSM not supported error status. And we then
> send a command reject for that. This is really stupid. What kernel
> version do you use and what kind of hardware is this? Can you
> reproduce it with the latest 2.4 or 2.6 kernel?

I guess the command reject is due to scid and dcid being both set to 0 by
the remote device. So bluez doesn't know who it's to talking to (as we can
have several cid on one ACL link) ...

I may be wrong but that sounds like an appropriated behaviour to me.

BR,
-- 
Xavier Garreau <xavier@xgarreau.org>
http://www.xgarreau.org

Re: [Bluez-devel] Disconnections are not being detected.

[Marcel Holtmann]

Hi Xavier,

> >> 1093025241.319200 > ACL data: handle 0x0006 flags 0x02 dlen 16
> >>     L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0000 result 2 status 0
> >> 1093025241.320195 < ACL data: handle 0x0006 flags 0x02 dlen 10
> >>     L2CAP(s): Command rej: reason 0
> 
> 
> > actually that is not quite right. The server (phone) sends back a
> > connect response with PSM not supported error status. And we then
> > send a command reject for that. This is really stupid. What kernel
> > version do you use and what kind of hardware is this? Can you
> > reproduce it with the latest 2.4 or 2.6 kernel?
> 
> I guess the command reject is due to scid and dcid being both set to 0 by
> the remote device. So bluez doesn't know who it's to talking to (as we can
> have several cid on one ACL link) ...

you are right. It should fill in dcid and scid. The remote device is
broken. Blame SE about that. I still don't know where the command reject
came from :(

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Disconnections are not being detected.

[Vlad]

Marcel and Xavier,

Thank you for such a prompt response to my post.  Here are some
more details regarding this problem.

As Marcel pointed out:

  actually that is not quite right. The server (phone) sends back a
  connect response with PSM not supported error status. And we then send a
  command reject for that. This is really stupid. What kernel version do
  you use and what kind of hardware is this? Can you reproduce it with the
  latest 2.4 or 2.6 kernel?

You right ... I didn't pay close attention to the direction where the
command reject packet is being sent. The above log came from the laptop
that was running kernel version 2.4.24, but I believe that such behavior
can be repeated on the more recent versions. [see below]


and as Xavier wrote:
 
  I guess the command reject is due to scid and dcid being both set to 0 by
  the remote device. So bluez doesn't know who it's to talking to (as we can
  have several cid on one ACL link) ...

Marcel wrote:

  you are right. It should fill in dcid and scid. The remote device is
  broken. Blame SE about that. I still don't know where the command reject
  came from :(

You are both right, about why is this happening. Here is a link to the
linux kernel source.

    http://lxr.linux.no/source/net/bluetooth/l2cap.c?v=2.4.26#L1450 

But the official L2CAP specification.  (Version 1.1) says (page 288):

	Result: 2 octets The result field indicates the outcome of
	the connection request. The result value of 0x0000 indicates
	success while a non-zero value indicates the connection request
	failed or is pending. A logical channel is established on the
	receipt of a successful result. Table 5.5 defines values for
	this field. If the result field is not zero. The DCID and SCID
	fields should be ignored when the result field indicates the
	connection was refused.

So although the BlueZ behavior is correct from common sense perspective,
but it is not correct from the specification perspective. I am not sure
what does version 1.2 of the spec say about this subject.


So since my project requires this to be implemented corrected. I will 
come up with some kind of patch for this and post in on this mailing
list. (Within next couple of weeks). Meanwhile I would appreciate any
suggestions on how this could be implemented with the least pain for
everybody.


						Vlad











-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Disconnections are not being detected.

[Marcel Holtmann]

Hi Vlad,

> But the official L2CAP specification.  (Version 1.1) says (page 288):
> 
> 	Result: 2 octets The result field indicates the outcome of
> 	the connection request. The result value of 0x0000 indicates
> 	success while a non-zero value indicates the connection request
> 	failed or is pending. A logical channel is established on the
> 	receipt of a successful result. Table 5.5 defines values for
> 	this field. If the result field is not zero. The DCID and SCID
> 	fields should be ignored when the result field indicates the
> 	connection was refused.
> 
> So although the BlueZ behavior is correct from common sense perspective,
> but it is not correct from the specification perspective. I am not sure
> what does version 1.2 of the spec say about this subject.

it is still the same for the 1.2 specification, but it is simply wrong
and stupid. You need at least the SCID to match the connect response to
a previous connect request. Otherwise this response is meaningless.

What we did wrong is sending the command reject for a response. I will
fix this, but this won't fix your problem. If we don't know for what
L2CAP channel we get a connection refused response, we can't do anything
else then waiting for a timeout event.

Check the bluetooth.org pages if they had an erratum for that and if not
ping them to correct it. Also write to SE about that.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Disconnections are not being detected

[andi.c]

ok, but how can my program be aware of this ? it has to do some tasks in =
response of
a link-fall.....


 >Hi Andrea,
 
 >> i am working on a=
 "pand" based that basically sets up bnep connections.
 > >For my tests,=
 i use simple usb bluetooth dongles (in particolar, some CSR
dongle).=0D
=
 > >My question is: how an endpoint (es a PANU) can detect a link lost ? =
I see
 > >w4_hup shuld
 > >handle this, but if i mnually remove the GN =
dongle, the PANU does"t signal
nothing.
 > >can someone help me ??
 =0D
=
 >the bnep0 ethernet device will disappear.
 
 >Regards
 
 >Marcel=0A=
=0A=0A=0A____________________________________________________________=0AR=
egala e regalati Libero ADSL: 3 mesi gratis, navighi veloce e scarichi a =
1.2 Mega. =0AAbbonati subito senza costi di attivazione su http://www.lib=
ero.it=0A=0A



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Disconnections are not being detected

[Marcel Holtmann]

Hi Andrea,

> ok, but how can my program be aware of this ? it has to do some tasks in response of
> a link-fall.....

since I never needed it so far, I don't know. Check the source code of
some unix tools or look at netlink.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel