* [Bluez-devel] Fwd: hci connect and switch role modifications
@ 2006-06-12 16:49 Marcello Cinque
2006-06-17 10:34 ` Marcel Holtmann
0 siblings, 1 reply; 3+ messages in thread
From: Marcello Cinque @ 2006-06-12 16:49 UTC (permalink / raw)
To: bluez-devel
[-- Attachment #1: Type: text/plain, Size: 5400 bytes --]
Hi Marcel,
in february I sent you the email in the following, about some proposed
modifications in the HCI connect and switch role APIs. At that time, I also attached
you the unified diff files, which I'm attaching also now.
Anyway, I didn't receive any reply. Do you think these modifications are
likely to be integrated in next releases?
Thanks,
Marcello.
Subject:
Re: [Bluez-devel] hci connect and switch role modifications
From:
Capaianca <fcornevilli@gmail.com>
Date:
Tue, 21 Feb 2006 17:03:36 +0100
To:
bluez-devel@lists.sourceforge.net
Hi Marcel,
as requested, we have attached the unified diff files of our
modifications. Basically, we added a couple mechanisms that may use to
prevent some errors from occurring (error masking mechanisms). The
mechanisms are part of the results of our research on bluetooth
networks. Perhaps the same strategies can be generalized and applied
on several parts of the code in order to improve the overall robustness
of the BlueZ stack.
Specifically, in the hci.c file (and related hci_lib.h) we added two
functions that may help to solve some problems which may arise when
creating connections or when switching the role. These functions are
called "hci_create_connection_timed" and "hci_switch_role_checked".
The hci_create_connection_timed function first creates a connection and
then checks whether the handle is valid (>0) until a given timeout
expires. The timeout is specified as an additional parameter, in
milliseconds.
We created this function because, while working with bluetooth, we
noticed that to get a valid handle over a connection may take some time,
even after that the hci_create_connection function return, due to the
asynchronous nature of the connection creation process. This could
result in a error when subsequent calls are performed over the
connection with a handle that is still not valid (e.g. a bnep create
connection call over an already created l2cap connection, or a switch
role command). This function avoids this problem because it returns with
no errors only if the created connection has a valid handle.
It is worth noting that the function returns a "timer expired (ETIME)"
error even when the connection is created. This happens when the timeout
expires but the connection still has a not valid handle. However, the
handle could become valid after the function exits.
The hci_switch_role_checked function performs a similar task. During our
tests we noticed that sometimes the hci_switch_role function exits with
a EIO error even if the role was actually switched. This problem may be
due to a temporary bad state of the rp.status value during the switch
role process attempt. To overcome this problem, after an invalid check
of rp.status value, our function reads the linkmode of the connection to
check the real status after a little amount of time (100ms in the
current version). If the role is not switched, further attempts are made
until a timeout expires. This timeout is provided as an input parameter
to our function.
This function resulted particularly useful when using PDA and other
limited resources devices where the time required to perform the switch
role may be longer and may result in errors signaled by the original
hci_switch_role function even if the role was actually switched.
We preferred to provide two new functions rather than modifying the
original ones. This way the user can choose to use the function that
better suites his requirements.
In order to test and use the new functionalities, we also slightly
modified the hcitool.c program, so as to add an optional parameter
"--timeout" to both the "cc" and "sr" commands. If the parameter is
specified the new functions are called, otherwise the original functions
are used.
Hope this can be of interest and help the BlueZ community.
Best regards,
Marcello Cinque
Fabio Cornevilli
Mobilab Research Group - www.mobilab.unina.it
Hi Marcello,
> we are working with Bluetooth and BlueZ since two years, and during the
> development of a field failure data analysis of Bluetooth networks, we
> experienced some annoying and frequent runtime errors that could be
> avoided.
> Those errors concern the creation of a L2CAP connection via HCI and
> the role
> switch operation. However, we discovered how to prevent these errors from
> occurring, by adding a little amount of code in the
> hci_create_connection and
> hci_switch_role functions in hci.c.
> We would like to contribute to the development and let the community
> know and
> evaluate these modifications.
>
> If you are interested, let us know what is the procedure to contribute.
>
simply sent a unified diff against the latest CVS to the mailing list.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
[-- Attachment #2: diffiles.tar.gz --]
[-- Type: application/gzip, Size: 2429 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
[-- Attachment #4: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bluez-devel] Fwd: hci connect and switch role modifications
2006-06-12 16:49 [Bluez-devel] Fwd: hci connect and switch role modifications Marcello Cinque
@ 2006-06-17 10:34 ` Marcel Holtmann
2006-07-31 13:01 ` Marcello Cinque
0 siblings, 1 reply; 3+ messages in thread
From: Marcel Holtmann @ 2006-06-17 10:34 UTC (permalink / raw)
To: BlueZ development
Hi Marcello,
> in february I sent you the email in the following, about some proposed
> modifications in the HCI connect and switch role APIs. At that time, I also attached
> you the unified diff files, which I'm attaching also now.
> Anyway, I didn't receive any reply. Do you think these modifications are
> likely to be integrated in next releases?
I might have missed that. Sorry, but this can happen from time to time.
If you propose multiple changes then please split them and post them
separately if possible. This makes it easier for me to review them and
then integrate them.
Regards
Marcel
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bluez-devel] Fwd: hci connect and switch role modifications
2006-06-17 10:34 ` Marcel Holtmann
@ 2006-07-31 13:01 ` Marcello Cinque
0 siblings, 0 replies; 3+ messages in thread
From: Marcello Cinque @ 2006-07-31 13:01 UTC (permalink / raw)
To: BlueZ development
[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]
Hi Marcel,
as you asked, i'll send you the modifications separately.
This is the first.
Basically, we added a mechanism that may use to prevent some errors
from occurring (error masking mechanism) when performing a
hci_create_connection. The mechanism is part of the results of our
research on bluetooth networks. Perhaps the same strategies can be
generalized and applied on several parts of the code in order to
improve the overall robustness of the BlueZ stack.
Specifically we added a function to the hci.c file (and related
hci_lib.h) which name is hci_create_connection_timed.
This function first creates a connection and then checks whether the
handle is valid (>0) until a given timeout expires. The timeout is
specified as an additional parameter, in milliseconds. We created this
function because, while working with bluetooth, we noticed that to get a
valid handle over a connection may take some time, even after that the
hci_create_connection function return, due to the asynchronous nature of
the connection creation process. This could result in a error when
subsequent calls are performed over the connection with a handle that is
still not valid (e.g. a bnep create connection call over an already
created l2cap connection, or a switch role command). This function
avoids this problem because it returns with no errors only if the
created connection has a valid handle.
It is worth noting that the function returns a "timer expired (ETIME)"
error even when the connection is created. This happens when the timeout
expires but the connection still has a not valid handle. However, the
handle could become valid after the function exits.
We preferred to provide a new function rather than modifying the
original ones. This way the user can choose to use the function that
better suites his requirements.
In order to test and use the new functionalities, we also slightly
modified the hcitool.c program, so as to add an optional parameter
"--timeout" to the "cc" command. If the parameter is specified the new
functions are called, otherwise the original functions are used.
Let me know if this can be of interest, in which case I'll send you also
the second modification, on the switch role command.
Best regards,
Marcello Cinque
Fabio Cornevilli
Mobilab Research Group - www.mobilab.unina.it
Marcel Holtmann wrote:
>Hi Marcello,
>
>
>
>>in february I sent you the email in the following, about some proposed
>>modifications in the HCI connect and switch role APIs. At that time, I also attached
>>you the unified diff files, which I'm attaching also now.
>>Anyway, I didn't receive any reply. Do you think these modifications are
>>likely to be integrated in next releases?
>>
>>
>
>I might have missed that. Sorry, but this can happen from time to time.
>
>If you propose multiple changes then please split them and post them
>separately if possible. This makes it easier for me to review them and
>then integrate them.
>
>Regards
>
>Marcel
>
>
>
>
>_______________________________________________
>Bluez-devel mailing list
>Bluez-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
--
Marcello Cinque, PhD Candidate
Dipartimento di Informatica e Sistemistica
Università di Napoli Federico II
Via Claudio, 21 - 80125 Napoli, Italy
Ph: +39-081-7683874
Fax: +39-081-7683816
Web: wpage.unina.it/macinque
The MobiLab Group - www.mobilab.unina.it
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
[-- Attachment #2: bluez_patches.tar.gz --]
[-- Type: application/gzip, Size: 1730 bytes --]
[-- Attachment #3: Type: text/plain, Size: 348 bytes --]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
[-- Attachment #4: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-07-31 13:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-12 16:49 [Bluez-devel] Fwd: hci connect and switch role modifications Marcello Cinque
2006-06-17 10:34 ` Marcel Holtmann
2006-07-31 13:01 ` Marcello Cinque
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).