Hi,
Doing "hcitool cc" under 2.6.18 establishes a connection and keeps it
open, which can be confirmed per "hcitool cc". Under 2.6.20 and 2.6.22 a
connection gets established, but is immediately (within 1-2 seconds)
broken. Is it a change in interfaces, is one supposed to connect
differently now, or is there a bug somewhere? It is hard to believe, that
such a bug could stay unnoticed and unfixed for at least 2 kernel
releases, so, has anything been changed in the API? As a partner a Linux
system with a 2.4.21 kernel is used. We have only tried thee three (.18,
.20, and .22) kernel versions so far.
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Guennadi,
> > as mentioned multiple times in the past, the "hcitool cc" is not a
> > general purpose command. Nobody needs to create an ACL link. The kernel
> > does this for you in the background and you should let the kernel do its
> > job. It has to be the kernel since it has to track these connections and
> > the users of it. Unused ACL links will be disconnected. Period.
> >
> > There are simply no excuses for creating low-level ACL links and there
> > is absolutely no need for it at all.
>
> Thanks, Marcel. Just, what I thought:-) It would've saved us a few minutes
> of typing and a few electrons shifted around the world if this was
> documented somewhere:-) Would be great, if someone could, for example,
> document it in the wiki. I DID look there, and I didn't find anything.
> Which means, either it is not there, or not everybody is able to find it
> there within a reasonable amount of time:-)
the documentation in various online articles is wrong. For some reason
people think that "hciool cc" is a good idea. It has always been a debug
command for developers. Nothing more, nothing less. The mailing list is
full of responses from me about it.
However the wiki is for everybody. Feel free to update it.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Tue, 7 Aug 2007, Marcel Holtmann wrote:
> as mentioned multiple times in the past, the "hcitool cc" is not a
> general purpose command. Nobody needs to create an ACL link. The kernel
> does this for you in the background and you should let the kernel do its
> job. It has to be the kernel since it has to track these connections and
> the users of it. Unused ACL links will be disconnected. Period.
>
> There are simply no excuses for creating low-level ACL links and there
> is absolutely no need for it at all.
Thanks, Marcel. Just, what I thought:-) It would've saved us a few minutes
of typing and a few electrons shifted around the world if this was
documented somewhere:-) Would be great, if someone could, for example,
document it in the wiki. I DID look there, and I didn't find anything.
Which means, either it is not there, or not everybody is able to find it
there within a reasonable amount of time:-)
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
Hi Guennadi,
> Doing "hcitool cc" under 2.6.18 establishes a connection and keeps it
> open, which can be confirmed per "hcitool cc". Under 2.6.20 and 2.6.22 a
> connection gets established, but is immediately (within 1-2 seconds)
> broken. Is it a change in interfaces, is one supposed to connect
> differently now, or is there a bug somewhere? It is hard to believe, that
> such a bug could stay unnoticed and unfixed for at least 2 kernel
> releases, so, has anything been changed in the API? As a partner a Linux
> system with a 2.4.21 kernel is used. We have only tried thee three (.18,
> .20, and .22) kernel versions so far.
as mentioned multiple times in the past, the "hcitool cc" is not a
general purpose command. Nobody needs to create an ACL link. The kernel
does this for you in the background and you should let the kernel do its
job. It has to be the kernel since it has to track these connections and
the users of it. Unused ACL links will be disconnected. Period.
There are simply no excuses for creating low-level ACL links and there
is absolutely no need for it at all.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Tue, 7 Aug 2007, Guennadi Liakhovetski wrote:
> Doing "hcitool cc" under 2.6.18 establishes a connection and keeps it
> open, which can be confirmed per "hcitool cc". Under 2.6.20 and 2.6.22 a
> connection gets established, but is immediately (within 1-2 seconds)
> broken. Is it a change in interfaces, is one supposed to connect
Just looked with hcidump, and it looks like it just sends the disconnect
request now... Here's the dump from 2.6.18:
1186499898.489550 < HCI Command: Create Connection (0x01|0x0005) plen 13
1186499898.496035 > HCI Event: Command Status (0x0f) plen 4
1186499901.854045 > HCI Event: Connect Complete (0x03) plen 11
1186499901.854072 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
1186499901.864062 > HCI Event: Command Status (0x0f) plen 4
1186499901.869054 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
1186499901.874058 > HCI Event: Max Slots Change (0x1b) plen 3
1186499901.904065 > HCI Event: Command Status (0x0f) plen 4
1186499901.904086 < HCI Command: Write Link Policy Settings (0x02|0x000d) plen 41186499901.914055 > HCI Event: Command Complete (0x0e) plen 6
1186499901.914073 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
1186499901.924061 > HCI Event: Command Status (0x0f) plen 4
1186499901.929055 > HCI Event: Read Remote Supported Features (0x0b) plen 11
1186499901.998030 > HCI Event: Remote Name Req Complete (0x07) plen 255
and under 2.6.22:
1186499587.139648 < HCI Command: Create Connection (0x01|0x0005) plen 13
1186499587.148291 > HCI Event: Command Status (0x0f) plen 4
1186499590.061422 > HCI Event: Connect Complete (0x03) plen 11
1186499590.061513 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
1186499590.069417 > HCI Event: Command Status (0x0f) plen 4
1186499590.071418 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
1186499590.074423 > HCI Event: Max Slots Change (0x1b) plen 3
1186499590.107440 > HCI Event: Command Status (0x0f) plen 4
1186499590.107522 < HCI Command: Write Link Policy Settings (0x02|0x000d) plen 41186499590.114417 > HCI Event: Command Complete (0x0e) plen 6
1186499590.114497 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
1186499590.120445 > HCI Event: Command Status (0x0f) plen 4
1186499590.127424 > HCI Event: Read Remote Supported Features (0x0b) plen 11
1186499590.164446 > HCI Event: Remote Name Req Complete (0x07) plen 255
1186499592.059386 < HCI Command: Disconnect (0x01|0x0006) plen 3
1186499592.063548 > HCI Event: Command Status (0x0f) plen 4
1186499592.091548 > HCI Event: Disconn Complete (0x05) plen 4
So, the only questions that remain are "why", and "how do I keep the
connection"?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users