T24gVGh1LCAyMDA3LTA1LTMxIGF0IDE2OjQ0ICswNTMwLCBBdmVlayBBdWRoeWEgd3JvdGU6Cj4g
SGksCj4gCj4gICAgICAgICAgICAgSSBhbSB0cnlpbmcgdG8gY29tbXVuaWNhdGUgd2l0aCBhIEoy
TUUgYXBwbGljYXRpb24gcnVubmluZwo+IG9uIG15IG1vYmlsZSBwaG9uZShOb2tpYSA2NjAwKSB1
c2luZyBhIGNsaWVudCBwcm9ncmFtIHJ1bm5pbmcgb24gYQo+IExpbnV4IG1hY2hpbmUgKEZDNiku
IFRoZSDigJhzZHB0b29sIGJyb3dzZeKAmSByZXBvcnRzIHRoYXQgdGhlIEoyTUUKPiBhcHBsaWNh
dGlvbiBpcyBsaXN0ZW5pbmcgb24gY2hhbm5lbCA0LiBUaGUgSjJNRSBhcHBsaWNhdGlvbiBpcyB1
c2luZwo+IGJ0c3BwIHByb3RvY29sIHdoZXJlYXMgbXkgY2xpZW50IHNpZGUgYXBwbGljYXRpb24g
aXMgdXNpbmcgUkZDT01NLiBCdXQKPiB3aGVuIEkgcnVuIHRoZSBjbGllbnQgYXBwbGljYXRpb24s
IHRoZSDigJhjb25uZWN04oCZIHN5c3RlbS1jYWxsIGZhaWxzCj4gKHJldHVybnMgLTEpIHdpdGgg
ZXJyb3IgdmFsdWUg4oCcT3BlcmF0aW9uIG5vdyBpbiBwcm9ncmVzc+KAnS4gSSBhbSB1c2luZwo+
IEJsdWVaIHByb3RvY29sIHN0YWNrLgo+IAo+IFdoYXQgY2FuIGJlIHRoZSBwcm9iYWJsZSByZWFz
b24gZm9yIHRoaXMga2luZCBvZiBiZWhhdmlvcj8gQW55Cj4gc3VnZ2VzdGlvbiBpcyBhcHByZWNp
YXRlZC4KCllvdSBwcm9iYWJseSBtYWRlIHRoZSBzb2NrZXQncyBmZCBub24tYmxvY2tpbmcuIEVp
dGhlciBtYWtlIGl0IGJsb2NraW5nLApvciBzZXR1cCBhIHdhdGNoZXIgb24gdGhlIGZkIHRvIHdh
aXQgZm9yIHRoZSBsaW5rIHRvIGJlIGNyZWF0ZWQuCgpTZWUgcmZjb21tX2Nvbm5lY3QoKSBpbiBi
bHVlei11dGlscy9zZXJpYWwvbWFuYWdlci5jCgotLSAKQmFzdGllbiBOb2NlcmEgPGhhZGVzc0Bo
YWRlc3MubmV0PiAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25z
b3JlZCBieSBEQjIgRXhwcmVzcwpEb3dubG9hZCBEQjIgRXhwcmVzcyBDIC0gdGhlIEZSRUUgdmVy
c2lvbiBvZiBEQjIgZXhwcmVzcyBhbmQgdGFrZQpjb250cm9sIG9mIHlvdXIgWE1MLiBObyBsaW1p
dHMuIEp1c3QgZGF0YS4gQ2xpY2sgdG8gZ2V0IGl0IG5vdy4KaHR0cDovL3NvdXJjZWZvcmdlLm5l
dC9wb3dlcmJhci9kYjIvCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fCkJsdWV6LWRldmVsIG1haWxpbmcgbGlzdApCbHVlei1kZXZlbEBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQKaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vYmx1
ZXotZGV2ZWwK
I didn't find any major difference between my application and 'manager.c' in
bluez-utils. The way it calls socket(), bind(), connect() etc are same as
what I am doing. Do you think it can be a baudrate problem as RFCOMM is a
serial communication after all? ...
-----Original Message-----
From: Bastien Nocera [mailto:[email protected]]
Sent: Friday, June 01, 2007 7:26 PM
To: BlueZ development
Cc: [email protected]
Subject: Re: [Bluez-devel] connect fail : Operation now in progress
On Fri, 2007-06-01 at 19:18 +0530, Aveek Audhya wrote:
> Hi Nocera,
>
> Thanks for your reply. What I have seen is that my socket's fd
> is by default blocking, every time it returns -1 after waiting for
> sometime. If I set it as non-blocking then it returns -1 immediately.
>
>
> I have set up a watcher with select() and getsockopt() call.
>
> It's like that ....
<snip>
> Unfortunately I couldn't find 'manager.c' in
> 'bluez-utils-3.9/serial/'. The folder doesn't contain any .c file
> except Makefile, Makefile.am and Makefile.in. 'manager.c' is present
> only in 'bluez-utils-3.9/daemon' folder, but there is no
> 'rfcomm_connect()' implementation. Probably we are using different
> utils version.
See in CVS, or in bluez-utils 3.11.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
T24gRnJpLCAyMDA3LTA2LTAxIGF0IDE5OjE4ICswNTMwLCBBdmVlayBBdWRoeWEgd3JvdGU6Cj4g
SGkgTm9jZXJhLAo+IAo+ICAgICAgIFRoYW5rcyBmb3IgeW91ciByZXBseS4gV2hhdCBJIGhhdmUg
c2VlbiBpcyB0aGF0IG15IHNvY2tldCdzIGZkCj4gaXMgYnkgZGVmYXVsdCBibG9ja2luZywgZXZl
cnkgdGltZSBpdCByZXR1cm5zIC0xIGFmdGVyIHdhaXRpbmcgZm9yCj4gc29tZXRpbWUuIElmIEkg
c2V0IGl0IGFzIG5vbi1ibG9ja2luZyB0aGVuIGl0IHJldHVybnMgLTEgaW1tZWRpYXRlbHkuCj4g
IAo+IAo+ICAgICAgIEkgaGF2ZSBzZXQgdXAgYSB3YXRjaGVyIHdpdGggc2VsZWN0KCkgYW5kIGdl
dHNvY2tvcHQoKSBjYWxsLiAKPiAKPiBJdCdzIGxpa2UgdGhhdCAuLi4uCjxzbmlwPgo+IFVuZm9y
dHVuYXRlbHkgSSBjb3VsZG7igJl0IGZpbmQg4oCYbWFuYWdlci5j4oCZIGluCj4g4oCYYmx1ZXot
dXRpbHMtMy45L3NlcmlhbC/igJkuIFRoZSBmb2xkZXIgZG9lc27igJl0IGNvbnRhaW4gYW55IC5j
IGZpbGUKPiBleGNlcHQgTWFrZWZpbGUsIE1ha2VmaWxlLmFtIGFuZCBNYWtlZmlsZS5pbi4g4oCY
bWFuYWdlci5j4oCZIGlzIHByZXNlbnQKPiBvbmx5IGluIOKAmGJsdWV6LXV0aWxzLTMuOS9kYWVt
b27igJkgZm9sZGVyLCBidXQgdGhlcmUgaXMgbm8KPiDigJhyZmNvbW1fY29ubmVjdCgp4oCZIGlt
cGxlbWVudGF0aW9uLiBQcm9iYWJseSB3ZSBhcmUgdXNpbmcgZGlmZmVyZW50Cj4gdXRpbHMgdmVy
c2lvbi4KClNlZSBpbiBDVlMsIG9yIGluIGJsdWV6LXV0aWxzIDMuMTEuCgotLSAKQmFzdGllbiBO
b2NlcmEgPGhhZGVzc0BoYWRlc3MubmV0PiAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoaXMgU0YubmV0
IGVtYWlsIGlzIHNwb25zb3JlZCBieSBEQjIgRXhwcmVzcwpEb3dubG9hZCBEQjIgRXhwcmVzcyBD
IC0gdGhlIEZSRUUgdmVyc2lvbiBvZiBEQjIgZXhwcmVzcyBhbmQgdGFrZQpjb250cm9sIG9mIHlv
dXIgWE1MLiBObyBsaW1pdHMuIEp1c3QgZGF0YS4gQ2xpY2sgdG8gZ2V0IGl0IG5vdy4KaHR0cDov
L3NvdXJjZWZvcmdlLm5ldC9wb3dlcmJhci9kYjIvCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCkJsdWV6LWRldmVsIG1haWxpbmcgbGlzdApCbHVlei1kZXZl
bEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlz
dHMvbGlzdGluZm8vYmx1ZXotZGV2ZWwK
Hi Nocera,
Thanks for your reply. What I have seen is that my socket's fd is by
default blocking, every time it returns -1 after waiting for sometime. If I
set it as non-blocking then it returns -1 immediately.
I have set up a watcher with select() and getsockopt() call.
It's like that ....
s = socket(AF_BLUETOOTH, SOCK_STREAM/*SOCK_SEQPACKET*/, BTPROTO_RFCOMM);
remote_addr.rc_family = AF_BLUETOOTH; // specifies the addressing family of
the socket
remote_addr.rc_channel = (uint8_t)4; // port no to connect to
str2ba(dest, &remote_addr.rc_bdaddr); // address to connect to
status = connect(s, (struct sockaddr*)&remote_addr, sizeof(struct
sockaddr_rc));
if(status < 0)
{
if(errno == EINPROGRESS)
{
printf("EINPROGRESS : %s\n",strerror(errno));
do
{
timeout.tv_sec = 25;
timeout.tv_usec = 0;
FD_ZERO(&wr);
FD_ZERO(&rd);
FD_ZERO(&exceptfds);
FD_SET(s,&wr);
FD_SET(s,&rd);
FD_SET(s,&exceptfds);
if((status =
select(s+1,&rd,&wr,&exceptfds,&timeout)) >0 )
{
//struct protoent *result;
len = sizeof(int);
//while((result = getprotoent()) != NULL)
//printf("name = %s, protocol =
%d\n",result->p_name,result->p_proto);
if(getsockopt(s,SOL_RFCOMM,SO_ERROR,(void*)&valopt,&len) <
0)
{
printf("Error in getsockopt() %d -
%s\n",errno,strerror(errno));
_exit(0);
}
if(valopt) // check the value returned
{
printf("Error in delayed connection() %d
- %s\n",valopt,strerror(valopt));
_exit(0);
}
printf("before break\n");
break;
}
else if(status < 0 && errno != EINTR)
{
printf("Error connecting %d - %s\n",errno,
strerror(errno));
_exit(0);
}
else
{
printf("errno = %d\n",errno);
perror("Timeout in select(). exiting... ");
_exit(0);
}
}while(1); /**/
}
else
{
printf("errno = %d\n",errno);
perror("Error in connect. exiting... ");
_exit(0);
}
}
But for SOL_RFCOMM in getsockopt() I get an error message at run time ..
Error in getsockopt() 92 - Protocol not available ..... although SOL_RFCOMM
is defined in '/usr/include/Bluetooth/bluetooth.h'. Is it the right way to
implement a watcher on a socket fd ?
One thing I forgot to mention that after making connect() call, my mobile
phone ask for 'accept connection request', and after pressing 'yes'
connect() returns -1 with error value 'Operation now in progress'.
Unfortunately I couldn't find 'manager.c' in 'bluez-utils-3.9/serial/'. The
folder doesn't contain any .c file except Makefile, Makefile.am and
Makefile.in. 'manager.c' is present only in 'bluez-utils-3.9/daemon' folder,
but there is no 'rfcomm_connect()' implementation. Probably we are using
different utils version.
Thanks again for your time.
-----Original Message-----
From: Bastien Nocera [mailto:[email protected]]
Sent: Thursday, May 31, 2007 8:38 PM
To: BlueZ development
Cc: [email protected]
Subject: Re: [Bluez-devel] connect fail : Operation now in progress
On Thu, 2007-05-31 at 16:44 +0530, Aveek Audhya wrote:
> Hi,
>
> I am trying to communicate with a J2ME application running
> on my mobile phone(Nokia 6600) using a client program running on a
> Linux machine (FC6). The 'sdptool browse' reports that the J2ME
> application is listening on channel 4. The J2ME application is using
> btspp protocol whereas my client side application is using RFCOMM. But
> when I run the client application, the 'connect' system-call fails
> (returns -1) with error value "Operation now in progress". I am using
> BlueZ protocol stack.
>
> What can be the probable reason for this kind of behavior? Any
> suggestion is appreciated.
You probably made the socket's fd non-blocking. Either make it blocking,
or setup a watcher on the fd to wait for the link to be created.
See rfcomm_connect() in bluez-utils/serial/manager.c
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel