Re: [Bluez-devel] RFComm channel allocation

Re: [Bluez-devel] RFComm channel allocation

[Max Krasnyansky]

At 06:40 AM 8/28/2003, Stephen Crane wrote:
>Hi,
>It seems that bind() on a sockaddr_rc doesn't check its channel
>argument: it allows binding to a channel number which then cannot be
>connect()ed to. (connect() seems to check this argument fine.)
>
>For example, I can bind a listening socket to channel 0 or 40:
>$ cat /proc/bluetooth/rfcomm
>sk  00:00:00:00:00:00 00:00:00:00:00:00 2 0
>sk  00:00:00:00:00:00 00:00:00:00:00:00 4 40
>
>$ cat /proc/bluetooth/rfcomm
>sk  00:00:00:00:00:00 00:00:00:00:00:00 2 0
>sk  00:00:00:00:00:00 00:00:00:00:00:00 4 0
Definitely a bug. The thing is that when we do bind() we don't call RFCOMM 
DLC layer (ie rfcomm_dlc_xxx stuff). connect() is calling rfcomm_dlc_open() 
which where channel validity check it performed.
I guess we'll have to add the same check in bind().

>On a related matter (and I'm pretty sure this /has/ come up before),
>would it be possible to perform automatic channel allocation in the
>kernel? 0 would be a good distinguishing value for this (since it is
>reserved to the RFComm multiplexer).
It's possible but does not seem to be needed. I mean so far nobody had
a strong argument why we need to support it.

Max



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] RFComm channel allocation

[Stephen Crane]

On Thu, 2003-10-09 at 01:52, Max Krasnyansky wrote:
> >On a related matter (and I'm pretty sure this /has/ come up before),
> >would it be possible to perform automatic channel allocation in the
> >kernel? 0 would be a good distinguishing value for this (since it is
> >reserved to the RFComm multiplexer).
> It's possible but does not seem to be needed. I mean so far nobody had
> a strong argument why we need to support it.

It seems to me that we're moving towards a more service-oriented view
where Bluetooth services are discovered by UUID rather than assuming
they live at a fixed port/channel number. 

If this is the case, servers shouldn't have to care what port/channel is
used, they just bind to any and use getsockname() to find out the actual
one allocated by the kernel, for subsequent advertisement by SDP. (Also
this is possible for AF_INET sockets, so it wouldn't violate the
principle of least surprise.)

Steve 
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

Re: [Bluez-devel] RFComm channel allocation

[Max Krasnyansky]

At 03:51 AM 10/9/2003, Stephen Crane wrote:
>On Thu, 2003-10-09 at 01:52, Max Krasnyansky wrote:
>> >On a related matter (and I'm pretty sure this /has/ come up before),
>> >would it be possible to perform automatic channel allocation in the
>> >kernel? 0 would be a good distinguishing value for this (since it is
>> >reserved to the RFComm multiplexer).
>> It's possible but does not seem to be needed. I mean so far nobody had
>> a strong argument why we need to support it.
>
>It seems to me that we're moving towards a more service-oriented view
>where Bluetooth services are discovered by UUID rather than assuming
>they live at a fixed port/channel number. 
>
>If this is the case, servers shouldn't have to care what port/channel is
>used, they just bind to any and use getsockname() to find out the actual
>one allocated by the kernel, for subsequent advertisement by SDP. (Also
>this is possible for AF_INET sockets, so it wouldn't violate the
>principle of least surprise.)

Well the thing is PSM 0 and Channel 0 are already used for bind() on the 
client side. It means "I do not need a port". Unlike IP clients Bluetooth 
clients do not need unique port.

Max