Setting up two connections at the same time

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?

Hi Herman,

Quoted 4 lines

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

Quoted 21 lines

Quoted 12 lines

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

Quoted 8 lines

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?

Quoted 7 lines

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?

Hi Herman,

Quoted 13 lines

Quoted 13 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 10 lines

Quoted 9 lines

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?

Quoted 2 lines

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.

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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?