Re: [Bluez-devel] Re: multi rfcomm/sco connection

[Marcel Holtmann <marcel@holtmann.org>]

Hi Radha,

> 1) We noticed that the SCO module has different behavior when dealing 
> with BDADDR_ANY as opposed to a specific bluetooth address. If a device 
> is told to listen for a SCO connection with BDADDR_ANY, and then creates 
> an outgoing SCO connection to a device using BDADDR_ANY, the connection 
> succeeds. Later, if an incoming SCO connection is received, the listen 
> socket will accept the connection (thus producing two SCO connections 
> over 2 ACL connections to 2 different devices).
> 
> This is all fine, but if instead, we bind the listen socket with a 
> specific device address (instead of BDADDR_ANY) and then try to make the 
> outgoing SCO connection using the specific address, it will fail 
> claiming that the address is already in use. This looks like 
> inconsistent behavior, given that even if we specify BDADDR_ANY and we 
> only have one interface, both connections will be using the same interface.
> 
> So, in short, if BlueZ is asked to use a specific interface for both 
> incoming and outgoing SCO connections, it will refuse to carry out the 
> bind calls, but if BDADDR_ANY is used, it will allow both connections. 
> Therefore, it appears to be a bug - either BlueZ really can't handle 
> more than one SCO at a time and it is being tricked into doing it, or it 
> should allow the user to specify the address and not complain.

there is a simply answer to that question. It is a bug :(

> 2) Consider two devices A and B. A uses BlueZ while B does not. Let us 
> also assume that B can handle more than one SCO per ACL connection.  Let 
> us say that there is a SCO connection between A and B already. Then B 
> initiates a second SCO connection on the same ACL to A. Looking at the 
> source for this situation, it appears that  the device A will overwrite 
> the SCO socket values with the new one that was just established (since 
> it allows only one SCO per ACL). Is this the intended behavior?

I read the source that the new SCO connection will be overwritten with
the value of the first one. However this still doesn't looks very nice
in any case.

Are you planning to use SCO over HCI or PCM?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel