Thread: bluetooth woes

Originally Posted by RedGTiVR6

cyber - please see the following thread: What causes a post to be moderated?

This is why your past 5 posts didn't show up.

Please be patient and one of the admins or mods will approve your post shortly.

Thanks That explains a lot...

I've been hacking the handsfree application to skip the +CMER commands as they seem to screw the connection up: the second CMER command doesn't return a value so everything hangs after that. Skipping the CMER commands gives me ERROR results for every command after that which I find weird as CMER only sets event messages on or off right? (Also it should be 3,0,0,1,0 = 5 parameters but that didn't help either).

I can reach phase 7 by skipping CMER but then the application hangs with a SCO connect failure. I have the SCO module loaded so why is it failing? I'm running as root - maybe that screws something up?

If I could just play with it, I can work around the restrictions...

Big thumbs up for the project though! I'm lousy with c but this might be the time to dive into it and help out

Edit:
running strace on the program shows all kinda of stuff for the TCP stack getting opened (including /etc/hosts) and my guess is that it dies here:

Code:

write(4294967295, "POST /push HTTP/1.1\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "Content-Length: 210\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
write(4294967295, "<?xml version=\"1.0\" encoding=\"UT"..., 210) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
read(4294967295, 0x7ffff28fc8e0, 800)   = -1 EBADF (Bad file descriptor)
close(4294967295)                       = -1 EBADF (Bad file descriptor)
socket(PF_BLUETOOTH, SOCK_SEQPACKET, 2) = 13
bind(13, {sa_family=AF_BLUETOOTH, sa_data="yP\20\335\t\0\0\0\0\0\r\0\0\0"}, 8) = 0
connect(13, {sa_family=AF_BLUETOOTH, sa_data="\364>\271\7\16\0\0\0\0\0\r\0\0\0"}, 8) = -1 ECONNREFUSED (Connection refused)
write(2, "connect: Connection refused\n", 28connect: Connection refused
) = 28
close(13)                               = 0
write(2, "Error: ", 7Error: )                  = 7
write(2, "Can't connect SCO audio channel "..., 51Can't connect SCO audio channel @ 00:0E:07:B9:3E:F4) = 51
write(2, "\n", 1
)                       = 1

So why doesn't it connect to.. errr... the AF_BLUETOOTH socket? (I guess?)

I tried running it all by hand the commands still give an error but +CMER does NOT kill the serial link so I don't understand why it does in the handsfree program - prolly bad coding?

Still leaves me with what cannot connect at the SCO layer? Does the program try to open a device node? Or a path to the phone? I don't really understand the call that fails so I can't figure out what goes wrong here...

On a different note: the SCO (voice) link, can I set that up by hand?

Originally Posted by cyberwizzard

I have the SCO module loaded so why is it failing? I'm running as root - maybe that screws something up?

I've been doing all my testing as root - I don't have any user accounts on my car computer

Originally Posted by cyberwizzard

running strace on the program shows all kinda of stuff for the TCP stack getting opened (including /etc/hosts) and my guess is that it dies here:

Code:

write(4294967295, "POST /push HTTP/1.1\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "Content-Length: 210\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
write(4294967295, "<?xml version=\"1.0\" encoding=\"UT"..., 210) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
read(4294967295, 0x7ffff28fc8e0, 800)   = -1 EBADF (Bad file descriptor)
close(4294967295)                       = -1 EBADF (Bad file descriptor)
socket(PF_BLUETOOTH, SOCK_SEQPACKET, 2) = 13
bind(13, {sa_family=AF_BLUETOOTH, sa_data="yP\20\335\t\0\0\0\0\0\r\0\0\0"}, 8) = 0
connect(13, {sa_family=AF_BLUETOOTH, sa_data="\364>\271\7\16\0\0\0\0\0\r\0\0\0"}, 8) = -1 ECONNREFUSED (Connection refused)
write(2, "connect: Connection refused\n", 28connect: Connection refused
) = 28
close(13)                               = 0
write(2, "Error: ", 7Error: )                  = 7
write(2, "Can't connect SCO audio channel "..., 51Can't connect SCO audio channel @ 00:0E:07:B9:3E:F4) = 51
write(2, "\n", 1
)                       = 1

So why doesn't it connect to.. errr... the AF_BLUETOOTH socket? (I guess?)

Hmm, that seems odd. I can't imagine why it would be writing HTTP requests to anything. Does that definitely come from the same program?

The connection refused error... that sounds like a pairing issue maybe. Make sure you've already got the phone paired up.

Originally Posted by cyberwizzard

I tried running it all by hand the commands still give an error but +CMER does NOT kill the serial link so I don't understand why it does in the handsfree program - prolly bad coding?

Still leaves me with what cannot connect at the SCO layer? Does the program try to open a device node? Or a path to the phone? I don't really understand the call that fails so I can't figure out what goes wrong here...

On a different note: the SCO (voice) link, can I set that up by hand?

AFAIK you cannot set up a SCO link manually. But you should be able to get everything but audio running using rfcomm and minicom (typing everything by hand). One phone I tested with would drop the connection if you didn't enter all the required commands within a few seconds, so I could only connect them by copy & pasting really quickly

Already ran everything by hand it using minicom and channel 3 and it worked fine so I don't understand why the connection seems to stall.

For the http stuff: yeah - its the same program...

I can connect to the phone using an rfcomm channel so I figured I paired it already - am I wrong here? If so, how do I properly pair it?

And to be clear - what fails to open, a SCO socket? can it be that I am missing something in my system? I even tried installing btsco + kernel driver but that doesn't work either

Update:
Still no luck - it keeps failing with the connection refused...

On a side note: I'm running amd64 gentoo, perhaps the 64-bit stuff works different?

Edit: Update:
I finally managed to pair my phone with audio using the btsco tool - so at least SCO links work on my system... Now I'm pondering why the handsfree application won't run...

Originally Posted by cyberwizzard

I finally managed to pair my phone with audio using the btsco tool - so at least SCO links work on my system... Now I'm pondering why the handsfree application won't run...

I haven't tried btsco yet. That's to connect from the PC to a headset, correct? Great news that you got SCO working... that means it looks like AMD 64 is supported

I am still working on the new handsfree stuff in sourceforge... my latest headache is figuring out when a BT socket's close() is complete (it is asynchronous and can take like 10 seconds to close an RFCOMM link).

Edit: Damn, it takes almost 20 seconds to cancel a connect(). Anybody know how to change the timeout on a socket? 20 seems a little high to me.

Another edit: in case anybody is interested... it looks like cancelling a connect makes it actually finish connecting before closing it. That's a pain. Necessary to wait it out though, since Bluez (well, probably all Bluetooth adapters) only supports one connection per channel at a time. So if you try to connect to some address on channel 3, then close the connection, then try a different address on the same channel very soon after, the connect will fail. You need to set SO_LINGER on the socket, then close it (it will take a while to flush out anything pending) before you can use that channel again.

Originally Posted by Zimans

Do you mean one connection per channel per device, or one connection period. Cause I can connect to two devices on the same channel at the same time.

Looked to me like one connection per channel period. Here's what I read in a SF mailing list archive:

You can not do this
while (0 > connect(s, (struct sockaddr *)&addr, sizeof(addr)))
if (errno != EBUSY) {
perror("connect");
return -1;
}

If connect returns EBUSY error you have to close() the socket. And it does
indeed return EBUSY in your case (I ran the progs) because close() is asynchronous
and that channel still exist (two connections on the same channel are not allowed
in RFCOMM). What you can do to avoid that error is to enable SO_LINGER option on that
socket, in which case close() will be synchronous.

I can't get to that thread anymore but the google cache is here:
SourceForge.net: bluez-devel

Of course, that was from 2003. So they may very well have added the capability for different devices connected on the same channel. But all I know is that when I close() the socket without SO_LINGER, and then try to make a new connection to the same phone, I get an error. I have not tried to a different phone though...... if indeed you can connect to a different phone while disconnecting from the first phone, that will have to be a version 2 feature

I just got a data cable for me phone so soon I can test whether newer firmware fixes the missing indicators I'm seeing.

Originally Posted by Zimans

Sounds to me that you can only have one connection per channel per device. But connect to as many devices as you wish. (Well, up to the limits of bluetooth).

That sounds reasonable.

Originally Posted by Zimans

Why are you closing a connection and then trying to immediately re-open it?

I want to make sure this library always behaves predictably. I don't want somebody to try to connect to their phone, then hit cancel, then change their mind and hit connect again a few seconds later and have everything go up in smoke. I'd rather the API let them know when they can and can't connect.

So I now have the following states in my API: disconnected, trying, negotiating, connected, and disconnecting. Disconnected means we're completely free, and ready to make an inbound or outbound connection. Trying means we're trying to make an outbound connection. Negotiating means we're connected and trying to establish a service-level connection. Connected means we're completely connected and should be ready to make/receive calls. Disconnecting means we're closing the socket and waiting for that to finish.

All of the code to make and handle these rfcomm connections is in place, just needs some more debugging and tweaking. I'm very frustrated with this phone though. There is no new firmware for it. But mine is really buggy. I will try some of the other phones I have lying around.

Edit: it all runs flawlessly with the motorola