* Re: [Bluez-devel] RFComm channel allocation [not found] <1062078007.1823.33.camel@baroque.rococosoft.com> @ 2003-10-09 0:52 ` Max Krasnyansky 2003-10-09 10:51 ` Stephen Crane 0 siblings, 1 reply; 3+ messages in thread From: Max Krasnyansky @ 2003-10-09 0:52 UTC (permalink / raw) To: Stephen Crane, bluez-devel; +Cc: marcel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bluez-devel] RFComm channel allocation 2003-10-09 0:52 ` [Bluez-devel] RFComm channel allocation Max Krasnyansky @ 2003-10-09 10:51 ` Stephen Crane 2003-10-09 17:58 ` Max Krasnyansky 0 siblings, 1 reply; 3+ messages in thread From: Stephen Crane @ 2003-10-09 10:51 UTC (permalink / raw) To: Max Krasnyansky; +Cc: bluez-devel, marcel 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) ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bluez-devel] RFComm channel allocation 2003-10-09 10:51 ` Stephen Crane @ 2003-10-09 17:58 ` Max Krasnyansky 0 siblings, 0 replies; 3+ messages in thread From: Max Krasnyansky @ 2003-10-09 17:58 UTC (permalink / raw) To: Stephen Crane; +Cc: bluez-devel, marcel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-10-09 17:58 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1062078007.1823.33.camel@baroque.rococosoft.com> 2003-10-09 0:52 ` [Bluez-devel] RFComm channel allocation Max Krasnyansky 2003-10-09 10:51 ` Stephen Crane 2003-10-09 17:58 ` Max Krasnyansky
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.