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
>
>