All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.