Hi All,
I am trying to develop an application which performs an inquiry and will
then perform a service search on the found devices using multiple
threads. This fails however because these threads all try to setup a
connection at the same time which is not possible off course. I have
traced the problem down to the HCI layer which sends a Command Status
event for the first Create Connection request indicating that it has
started the connection setup. But the Command Status event indicates to
the host that it is ready to receive the next HCI command. However the
next command in the queue is the second Create Connection request which
is then sent to the HCI controller. The controller off course rejects
this request with a status 0x0C (Command Disallowed). This error is
propagated to the higher layers (l2cap and sdp) and eventually the
sdp_connect fails with errno set to EBADFD.
What is the best way to handle this situation? The EBADFD doesn't really
indicate that the application can retry the request. Wouldn't it be
better to handle this at the host HCI layer? That is the only entity
which can possibly keep track of the HCI controller state and perform
the next connection request only when the Connection Complete event from
the previous request has been received. This way the requests could be
serialized. Or is this way too complex?
Regards,
Herman Meerlo
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
>>>>thanks for your reply. It is not only a problem if one single
>>>>application tries to set-up multiple connections simultaneously, it will
>>>>also fail if two independent applications on one machine try to setup a
>>>>connection. This makes bluetooth an unreliable medium from an end-user
>>>>perspective because connection set-up may fail randomly because of this.
>>>>This will off course not happen extremely often. However I think that
>>>>this problem could be solved at HCI level which can keep track of the
>>>>controller state. E.g. it could hold up any Connection Request until the
>>>>previous one has finished. Or am I missing something?
>>>>
>>>>
>>>feel free to propose something to support this. However this must be
>>>done at kernel level in the Bluetooth core HCI functions.
>>>
>>>
>>I was afraid you were going to say this :-) I completely agree with you
>>and I hope my boss will give me the time to think about this and let me
>>make a prototype. In the meantime I will probably try to workaround this
>>with multiple dongles.
>>
>>
>
>and btw you will see similar problems with inquiry and remote name
>requests at the same time. You might need to serialize all of them.
>
>An interesting question is how any of Windows stacks handles this? Are
>they capable of dealing with it or do they act like Linux?
>
>
>
>
two minds, one thought. I was thinking exactly the same. I did indeed
see the same problems with remote name requests (I already serialized
the inquiry process in my application). Maybe I will try to make a test
set-up for this to see how windows behaves.
Regards,
Herman
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Herman,
> >>thanks for your reply. It is not only a problem if one single
> >>application tries to set-up multiple connections simultaneously, it will
> >>also fail if two independent applications on one machine try to setup a
> >>connection. This makes bluetooth an unreliable medium from an end-user
> >>perspective because connection set-up may fail randomly because of this.
> >>This will off course not happen extremely often. However I think that
> >>this problem could be solved at HCI level which can keep track of the
> >>controller state. E.g. it could hold up any Connection Request until the
> >>previous one has finished. Or am I missing something?
> >
> >feel free to propose something to support this. However this must be
> >done at kernel level in the Bluetooth core HCI functions.
>
> I was afraid you were going to say this :-) I completely agree with you
> and I hope my boss will give me the time to think about this and let me
> make a prototype. In the meantime I will probably try to workaround this
> with multiple dongles.
and btw you will see similar problems with inquiry and remote name
requests at the same time. You might need to serialize all of them.
An interesting question is how any of Windows stacks handles this? Are
they capable of dealing with it or do they act like Linux?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>Hi Herman,
>
>
>
>>>>I am trying to develop an application which performs an inquiry and will
>>>>then perform a service search on the found devices using multiple
>>>>threads. This fails however because these threads all try to setup a
>>>>connection at the same time which is not possible off course. I have
>>>>traced the problem down to the HCI layer which sends a Command Status
>>>>event for the first Create Connection request indicating that it has
>>>>started the connection setup. But the Command Status event indicates to
>>>>the host that it is ready to receive the next HCI command. However the
>>>>next command in the queue is the second Create Connection request which
>>>>is then sent to the HCI controller. The controller off course rejects
>>>>this request with a status 0x0C (Command Disallowed). This error is
>>>>propagated to the higher layers (l2cap and sdp) and eventually the
>>>>sdp_connect fails with errno set to EBADFD.
>>>>What is the best way to handle this situation? The EBADFD doesn't really
>>>>indicate that the application can retry the request. Wouldn't it be
>>>>better to handle this at the host HCI layer? That is the only entity
>>>>which can possibly keep track of the HCI controller state and perform
>>>>the next connection request only when the Connection Complete event from
>>>>the previous request has been received. This way the requests could be
>>>>serialized. Or is this way too complex?
>>>>
>>>>
>>>the same question came already came up some time ago. I don't know of
>>>any Bluetooth chip that allows to establish multiple baseband links at
>>>the same time. I personally think that such a chip will never be build,
>>>because it is way to expensive. Once you received the Connection
>>>Complete event you can ask the chip to establish another link to another
>>>device. Or you simply use multiple dongles for this task.
>>>
>>>
>>>
>>thanks for your reply. It is not only a problem if one single
>>application tries to set-up multiple connections simultaneously, it will
>>also fail if two independent applications on one machine try to setup a
>>connection. This makes bluetooth an unreliable medium from an end-user
>>perspective because connection set-up may fail randomly because of this.
>>This will off course not happen extremely often. However I think that
>>this problem could be solved at HCI level which can keep track of the
>>controller state. E.g. it could hold up any Connection Request until the
>>previous one has finished. Or am I missing something?
>>
>>
>
>feel free to propose something to support this. However this must be
>done at kernel level in the Bluetooth core HCI functions.
>
>
>
>
I was afraid you were going to say this :-) I completely agree with you
and I hope my boss will give me the time to think about this and let me
make a prototype. In the meantime I will probably try to workaround this
with multiple dongles.
Regards,
Herman
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Herman,
> >>I am trying to develop an application which performs an inquiry and will
> >>then perform a service search on the found devices using multiple
> >>threads. This fails however because these threads all try to setup a
> >>connection at the same time which is not possible off course. I have
> >>traced the problem down to the HCI layer which sends a Command Status
> >>event for the first Create Connection request indicating that it has
> >>started the connection setup. But the Command Status event indicates to
> >>the host that it is ready to receive the next HCI command. However the
> >>next command in the queue is the second Create Connection request which
> >>is then sent to the HCI controller. The controller off course rejects
> >>this request with a status 0x0C (Command Disallowed). This error is
> >>propagated to the higher layers (l2cap and sdp) and eventually the
> >>sdp_connect fails with errno set to EBADFD.
> >>What is the best way to handle this situation? The EBADFD doesn't really
> >>indicate that the application can retry the request. Wouldn't it be
> >>better to handle this at the host HCI layer? That is the only entity
> >>which can possibly keep track of the HCI controller state and perform
> >>the next connection request only when the Connection Complete event from
> >>the previous request has been received. This way the requests could be
> >>serialized. Or is this way too complex?
> >
> >the same question came already came up some time ago. I don't know of
> >any Bluetooth chip that allows to establish multiple baseband links at
> >the same time. I personally think that such a chip will never be build,
> >because it is way to expensive. Once you received the Connection
> >Complete event you can ask the chip to establish another link to another
> >device. Or you simply use multiple dongles for this task.
> >
> thanks for your reply. It is not only a problem if one single
> application tries to set-up multiple connections simultaneously, it will
> also fail if two independent applications on one machine try to setup a
> connection. This makes bluetooth an unreliable medium from an end-user
> perspective because connection set-up may fail randomly because of this.
> This will off course not happen extremely often. However I think that
> this problem could be solved at HCI level which can keep track of the
> controller state. E.g. it could hold up any Connection Request until the
> previous one has finished. Or am I missing something?
feel free to propose something to support this. However this must be
done at kernel level in the Bluetooth core HCI functions.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Marcel Holtmann wrote:
>Hi Herman,
>
>
>
>>I am trying to develop an application which performs an inquiry and will
>>then perform a service search on the found devices using multiple
>>threads. This fails however because these threads all try to setup a
>>connection at the same time which is not possible off course. I have
>>traced the problem down to the HCI layer which sends a Command Status
>>event for the first Create Connection request indicating that it has
>>started the connection setup. But the Command Status event indicates to
>>the host that it is ready to receive the next HCI command. However the
>>next command in the queue is the second Create Connection request which
>>is then sent to the HCI controller. The controller off course rejects
>>this request with a status 0x0C (Command Disallowed). This error is
>>propagated to the higher layers (l2cap and sdp) and eventually the
>>sdp_connect fails with errno set to EBADFD.
>>What is the best way to handle this situation? The EBADFD doesn't really
>>indicate that the application can retry the request. Wouldn't it be
>>better to handle this at the host HCI layer? That is the only entity
>>which can possibly keep track of the HCI controller state and perform
>>the next connection request only when the Connection Complete event from
>>the previous request has been received. This way the requests could be
>>serialized. Or is this way too complex?
>>
>>
>
>the same question came already came up some time ago. I don't know of
>any Bluetooth chip that allows to establish multiple baseband links at
>the same time. I personally think that such a chip will never be build,
>because it is way to expensive. Once you received the Connection
>Complete event you can ask the chip to establish another link to another
>device. Or you simply use multiple dongles for this task.
>
>Regards
>
>Marcel
>
>
>
>
thanks for your reply. It is not only a problem if one single
application tries to set-up multiple connections simultaneously, it will
also fail if two independent applications on one machine try to setup a
connection. This makes bluetooth an unreliable medium from an end-user
perspective because connection set-up may fail randomly because of this.
This will off course not happen extremely often. However I think that
this problem could be solved at HCI level which can keep track of the
controller state. E.g. it could hold up any Connection Request until the
previous one has finished. Or am I missing something?
P.S. There will probably never be a chipset that allows to establish
multiple baseband links unless it has multiple basbeband controllers.
This is because the it has to follow a certain hopping sequence for the
paging procedure and therefore cannot follow two hopping sequences to
listen for page repsonse packets.
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Herman,
> I am trying to develop an application which performs an inquiry and will
> then perform a service search on the found devices using multiple
> threads. This fails however because these threads all try to setup a
> connection at the same time which is not possible off course. I have
> traced the problem down to the HCI layer which sends a Command Status
> event for the first Create Connection request indicating that it has
> started the connection setup. But the Command Status event indicates to
> the host that it is ready to receive the next HCI command. However the
> next command in the queue is the second Create Connection request which
> is then sent to the HCI controller. The controller off course rejects
> this request with a status 0x0C (Command Disallowed). This error is
> propagated to the higher layers (l2cap and sdp) and eventually the
> sdp_connect fails with errno set to EBADFD.
> What is the best way to handle this situation? The EBADFD doesn't really
> indicate that the application can retry the request. Wouldn't it be
> better to handle this at the host HCI layer? That is the only entity
> which can possibly keep track of the HCI controller state and perform
> the next connection request only when the Connection Complete event from
> the previous request has been received. This way the requests could be
> serialized. Or is this way too complex?
the same question came already came up some time ago. I don't know of
any Bluetooth chip that allows to establish multiple baseband links at
the same time. I personally think that such a chip will never be build,
because it is way to expensive. Once you received the Connection
Complete event you can ask the chip to establish another link to another
device. Or you simply use multiple dongles for this task.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel