* [Bluez-users] sockets connect before accept()
@ 2004-01-29 16:43 Jan Bandouch
2004-01-31 9:42 ` Jan Bandouch
0 siblings, 1 reply; 3+ messages in thread
From: Jan Bandouch @ 2004-01-29 16:43 UTC (permalink / raw)
To: bluez-users
Hello,
I'm developing a Bluetooth Client/Server application with the client
being a Palm Handheld and the Server being a linux PC using BlueZ
(Debian Kernel 2.4.22, libbluetooth1-dev version 2.5-1).
My client programm (PalmOS) does the following:
1) Establish an Acl Link to the server (address and channel is hardcoded)
2) Create and Connect an RfComm socket to the server (address/channel
still hardcoded)
The connection does get established all right.
The funny thing is, that on the server side all I did was to create a
RfComm socket, bind that socket to BDADDR_ANY and channel 10, and
listen. Thats all. No accept(..) call, no select(..) etc.
I can do a select(..), but I never get told of any connection requests.
I believe that is because my connection request was already handled
before calling select(..).
But why or by whom? I'm new to socket programming, but as far as I know
this is not the way it's supposed to work, or is it? And BlueZ
programming should work similar to socket programming, or not?
And how am I supposed to get a socket handler for the data socket
without calling accept(..)?
Some more info:
The rfcomm-module is not in use, before I start my server programm.
After the client establishes the connection, "cat
/proc/bluetooth/rfcomm" shows the following information:
dlc EF:30:04:72:02:00 94:A1:10:E0:07:00 1 20 127 40 1
sk EF:30:04:72:02:00 94:A1:10:E0:07:00 1 10
sk 00:00:00:00:00:00 00:00:00:00:00:00 4 10
the last line is my listening socket, the first two seem to be the
connection "initiated" by the Palm. Any infos on how to read the above
information? what does "dlc" stand for, and the numbers on the right?
Any help appreciated. At first I thought that some other process accepts
the connection, but the connection gets only established after listening
on my socket.
Thanks,
Jan
By the way, any documentation, links regarding BlueZ programming are
welcome! I know the site of Marcel Holtmann, but there's only one
article dealing with programming, and it's seems I could use some more :-)
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bluez-users] sockets connect before accept()
2004-01-29 16:43 [Bluez-users] sockets connect before accept() Jan Bandouch
@ 2004-01-31 9:42 ` Jan Bandouch
2004-01-31 15:13 ` Marcel Holtmann
0 siblings, 1 reply; 3+ messages in thread
From: Jan Bandouch @ 2004-01-31 9:42 UTC (permalink / raw)
To: bluez-users
Hi,
I've finally figured out how to establish the connection correctly via
select(..). Was my error in interpreting the return code.
The main problem seems to be on the Palm side, because it gets the
connection established event, even if it isn't really established (but
somehow pending), cause I didn't yet accept it on the server side. This
is strange behavior in my opinion, but well, thats how it seems to be.
But I would still be interested in someone who can tell me what's the
exact information that "cat /proc/bluetooth/rfcomm" gives me. Or a hint
where to find this information.
Thanks,
Jan
Jan Bandouch wrote:
> Hello,
> I'm developing a Bluetooth Client/Server application with the client
> being a Palm Handheld and the Server being a linux PC using BlueZ
> (Debian Kernel 2.4.22, libbluetooth1-dev version 2.5-1).
>
> My client programm (PalmOS) does the following:
> 1) Establish an Acl Link to the server (address and channel is hardcoded)
> 2) Create and Connect an RfComm socket to the server (address/channel
> still hardcoded)
>
> The connection does get established all right.
> The funny thing is, that on the server side all I did was to create a
> RfComm socket, bind that socket to BDADDR_ANY and channel 10, and
> listen. Thats all. No accept(..) call, no select(..) etc.
> I can do a select(..), but I never get told of any connection requests.
> I believe that is because my connection request was already handled
> before calling select(..).
> But why or by whom? I'm new to socket programming, but as far as I know
> this is not the way it's supposed to work, or is it? And BlueZ
> programming should work similar to socket programming, or not?
> And how am I supposed to get a socket handler for the data socket
> without calling accept(..)?
>
> Some more info:
> The rfcomm-module is not in use, before I start my server programm.
> After the client establishes the connection, "cat
> /proc/bluetooth/rfcomm" shows the following information:
>
> dlc EF:30:04:72:02:00 94:A1:10:E0:07:00 1 20 127 40 1
> sk EF:30:04:72:02:00 94:A1:10:E0:07:00 1 10
> sk 00:00:00:00:00:00 00:00:00:00:00:00 4 10
>
> the last line is my listening socket, the first two seem to be the
> connection "initiated" by the Palm. Any infos on how to read the above
> information? what does "dlc" stand for, and the numbers on the right?
>
> Any help appreciated. At first I thought that some other process accepts
> the connection, but the connection gets only established after listening
> on my socket.
>
> Thanks,
>
> Jan
>
>
>
> By the way, any documentation, links regarding BlueZ programming are
> welcome! I know the site of Marcel Holtmann, but there's only one
> article dealing with programming, and it's seems I could use some more :-)
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bluez-users] sockets connect before accept()
2004-01-31 9:42 ` Jan Bandouch
@ 2004-01-31 15:13 ` Marcel Holtmann
0 siblings, 0 replies; 3+ messages in thread
From: Marcel Holtmann @ 2004-01-31 15:13 UTC (permalink / raw)
To: Jan Bandouch; +Cc: BlueZ Mailing List
Hi Jan,
> I've finally figured out how to establish the connection correctly via
> select(..). Was my error in interpreting the return code.
> The main problem seems to be on the Palm side, because it gets the
> connection established event, even if it isn't really established (but
> somehow pending), cause I didn't yet accept it on the server side. This
> is strange behavior in my opinion, but well, thats how it seems to be.
>
> But I would still be interested in someone who can tell me what's the
> exact information that "cat /proc/bluetooth/rfcomm" gives me. Or a hint
> where to find this information.
look at rctest for an example or show us your code.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-01-31 15:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-29 16:43 [Bluez-users] sockets connect before accept() Jan Bandouch
2004-01-31 9:42 ` Jan Bandouch
2004-01-31 15:13 ` Marcel Holtmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.