From: Vlad <vkorolev@nist.gov>
To: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] Re: Disconnections are not being detected.
Date: Fri, 27 Aug 2004 00:17:08 +0000 (UTC) [thread overview]
Message-ID: <loom.20040827T021529-764@post.gmane.org> (raw)
In-Reply-To: 1093083055.3650.7.camel@notepaq
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
next prev parent reply other threads:[~2004-08-27 0:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-20 18:47 [Bluez-devel] Disconnections are not being detected Vlad
2004-08-21 7:28 ` Marcel Holtmann
2004-08-21 8:02 ` Xavier GARREAU
2004-08-21 10:10 ` Marcel Holtmann
2004-08-27 0:17 ` Vlad [this message]
2004-08-27 11:33 ` [Bluez-devel] " Marcel Holtmann
-- strict thread matches above, loose matches on Subject: below --
2004-12-16 10:43 andi.c
2004-12-16 11:10 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20040827T021529-764@post.gmane.org \
--to=vkorolev@nist.gov \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox