Binding RFCOMM sockets

Hey all!

I'm currently trying to implement a server over the RFCOMM
layer, and at least 
my imagination told me that connecting to channel 0 should
select "any" free 
RFCOMM channel (at least that's what I gathered from the
BlueZ documentation, 
which of course has nothing to do with the FreeBSD bluetooth
stack, but 
anyway ).

Anyway, binding to the 0 channel succeeds (with getsockname
getting back the 0 
channel afterwards even though the socket is [supposedly]
bound), but calling 
listen() then gives me a EDESTADDRREQ, which I can't really
sort into the 
problem, as it isn't documented in man 2 listen either.

I've not tried to bind to a specific channel (yet), but
anyway, just wanted to 
ask you guys whether there is any proper
"protocol" for binding to a wildcard 
(free) RFCOMM channel using the standard socket API (and no,
I don't actually 
want to test each channel whether it's free, which was
necessary with an 
older version of BlueZ, at least according to their API
documentation).

By the way, the system is a 6.2-STABLE.

Thanks for any hint!

-- 
Heiko Wundram
Product & Application Development
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

Hello,

> I'm currently trying to implement a server over the
RFCOMM layer, and at least
> my imagination told me that connecting to channel 0
should select "any" free
> RFCOMM channel (at least that's what I gathered from
the BlueZ documentation,
> which of course has nothing to do with the FreeBSD
bluetooth stack, but
> anyway ).

this is not currently implemented in freebsd

> Anyway, binding to the 0 channel succeeds (with
getsockname getting back the 0
> channel afterwards even though the socket is
[supposedly] bound), but calling
> listen() then gives me a EDESTADDRREQ, which I can't
really sort into the
> problem, as it isn't documented in man 2 listen
either.

basically it is trying to tell you that local address is
invalid.

> I've not tried to bind to a specific channel (yet), but
anyway, just wanted to
> ask you guys whether there is any proper
"protocol" for binding to a wildcard
> (free) RFCOMM channel using the standard socket API
(and no, I don't actually
> want to test each channel whether it's free, which was
necessary with an
> older version of BlueZ, at least according to their API
documentation).

like i said, this is currently not supported. wildcard
addressing
currently only supported for

1) bd_addr's (both incoming and outgoing connections for
rfcomm and l2cap)

2) channel/psm (only for outgoing connections for
rfcomm/l2cap)

the assumption i made here is that server needs to know
exact rfcomm
channel to listen on. mostly because i was not sure how to
deal with
wildcard addressing when multiple bluetooth devices
connected to the
same system.

anyway, i will put this on my todo list and hopefully will
get to it.
no promises though  you are
welcome to submit patches btw. i will be
more than happy to review and commit them for you.

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Tue, 21 Aug 2007, Maksim Yevmenkin wrote:

> > I'm currently trying to implement a server over
the RFCOMM layer, and at least
> > my imagination told me that connecting to channel
0 should select "any" free
> > RFCOMM channel (at least that's what I gathered
from the BlueZ documentation,
> > which of course has nothing to do with the FreeBSD
bluetooth stack, but
> > anyway ).
>
> this is not currently implemented in freebsd

nor in NetBSD - out of interest though, what is this server
trying to
achieve? It does not seem especially useful to listen on
'any' channel,
given the way that bluetooth service discovery works..

btw where is this API documentation for BlueZ that you
mention? I never
managed to find anything like that as I recall..

> > Anyway, binding to the 0 channel succeeds (with
getsockname getting back the 0
> > channel afterwards even though the socket is
[supposedly] bound), but calling
> > listen() then gives me a EDESTADDRREQ, which I
can't really sort into the
> > problem, as it isn't documented in man 2 listen
either.
>
> basically it is trying to tell you that local address
is invalid.

(Max, maybe EADDRNOTAVAIL is better for that?)

iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On 8/21/07, Iain Hibbert <plunkyrya-online.net> wrote:
> On Tue, 21 Aug 2007, Maksim Yevmenkin wrote:
>
> > > I'm currently trying to implement a server
over the RFCOMM layer, and at least
> > > my imagination told me that connecting to
channel 0 should select "any" free
> > > RFCOMM channel (at least that's what I
gathered from the BlueZ documentation,
> > > which of course has nothing to do with the
FreeBSD bluetooth stack, but
> > > anyway ).
> >
> > this is not currently implemented in freebsd
>
> nor in NetBSD - out of interest though, what is this
server trying to
> achieve? It does not seem especially useful to listen
on 'any' channel,
> given the way that bluetooth service discovery works..

well, the idea, imo, is when a server binds to 'any' channel
(or psm),
the kernel will automatically assign first available one.
next, the
application calls getsockname(2) to obtain the actual
channel (or psm)
that was assigned by the kernel and registers that channel
(or psm)
with sdp.

this simplifies resource (i.e. channel or psm) management
when
multiple applications are trying to provide multiple
services at the
same time. basically you do not have to worry about
assigning channels
(or psm's) by hand.

> btw where is this API documentation for BlueZ that you
mention? I never
> managed to find anything like that as I recall..

its part of the standard socket api, i.e. for tcp sockets it
would
look something like

        bzero(&sin, sizeof(sin));
        sin.sin_len = sizeof(sin);
        sin.sin_family = AF_INET;
        sin.sin_addr.s_addr = htonl(INADDR_ANY);
        sin.sin_port = 0;

        s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

        bind(s, (struct sockaddr *) &sin, sizeof(sin);

        listen(s, 10);

        len = sizeof(sin);
        getsockname(s, (struct sockaddr *) &sin,
&len);

> > > Anyway, binding to the 0 channel succeeds
(with getsockname getting back the 0
> > > channel afterwards even though the socket is
[supposedly] bound), but calling
> > > listen() then gives me a EDESTADDRREQ, which
I can't really sort into the
> > > problem, as it isn't documented in man 2
listen either.
> >
> > basically it is trying to tell you that local
address is invalid.
>
> (Max, maybe EADDRNOTAVAIL is better for that?)

yes, i suppose it is.

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

Am Mittwoch 22 August 2007 23:21:51 schrieb Maksim
Yevmenkin:
> On 8/21/07, Iain Hibbert <plunkyrya-online.net> wrote:
> > nor in NetBSD - out of interest though, what is
this server trying to
> > achieve? It does not seem especially useful to
listen on 'any' channel,
> > given the way that bluetooth service discovery
works..
>
> well, the idea, imo, is when a server binds to 'any'
channel (or psm),
> the kernel will automatically assign first available
one. next, the
> application calls getsockname(2) to obtain the actual
channel (or psm)
> that was assigned by the kernel and registers that
channel (or psm)
> with sdp.
>
> this simplifies resource (i.e. channel or psm)
management when
> multiple applications are trying to provide multiple
services at the
> same time. basically you do not have to worry about
assigning channels
> (or psm's) by hand.

This is exactly what I had in mind. Generally, what I'm
currently building is 
an OBEX service framework which depending on the channel the
remote 
application connects to should offer differing kinds of
backend services.

As the services themselves are fairly independent, I
generally found the idea 
to have the kernel decide which channel to use for a
specific was pretty much 
similar to what the portmapper does for TCP/IP, where a
listening socket is 
bound if it wasn't on the listen command, and you can then
retrieve the local 
address using getsockname() to register that port with the
portmapper.

Anyway, as you said you'd accept a patch from me, I'm
currently trying to hack 
this into my 6.2-STABLE. I'll be able to tell you whether
I'll manage to get 
this working by the end of the weekend; (FreeBSD)
kernel-programming is 
utterly new for me. 

-- 
Heiko Wundram
Product & Application Development
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"