From owner-freebsd-bluetooth@FreeBSD.ORG  Tue Aug 21 16:51:26 2007
Return-Path: <owner-freebsd-bluetooth@FreeBSD.ORG>
Delivered-To: freebsd-bluetooth@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 119B816A41B
	for <freebsd-bluetooth@freebsd.org>;
	Tue, 21 Aug 2007 16:51:26 +0000 (UTC)
	(envelope-from maksim.yevmenkin@gmail.com)
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190])
	by mx1.freebsd.org (Postfix) with ESMTP id 857C113C48A
	for <freebsd-bluetooth@freebsd.org>;
	Tue, 21 Aug 2007 16:51:25 +0000 (UTC)
	(envelope-from maksim.yevmenkin@gmail.com)
Received: by nf-out-0910.google.com with SMTP id b2so999364nfb
	for <freebsd-bluetooth@freebsd.org>;
	Tue, 21 Aug 2007 09:51:24 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=oPohzU3tkjfwHHEB8u9X4lwVwl2gLH11yt3qxrZGvc8wc7bP6nW6uKTxTBWTRC5eR3xpuj0CEiWmfbzpXnlVGRp4mco6nAx73LG7IOveplGw7s4yNw0W0UYSV9vu7JE5paC+zMhfBD386ocmadFiKhkwWwQRI7ByLS3vfuzddzM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=nbv+blGGkgLPnuhL+IIvW6S2EKOJhJ5hrjXMY6i301pNnbhVa8yBpHHlMs8pWcYsIWVAnVzDrPCOjrj+YEAMtk0G/I4ZBa17d3RCc/xMqsNON2ZovSwh9ndF4bmxJqF04wZKUa7LEuLpvGTAo5na1MMy9ULL58IL7AM/mlxW3B4=
Received: by 10.86.50.8 with SMTP id x8mr5578704fgx.1187715084063;
	Tue, 21 Aug 2007 09:51:24 -0700 (PDT)
Received: by 10.86.25.9 with HTTP; Tue, 21 Aug 2007 09:51:24 -0700 (PDT)
Message-ID: <bb4a86c70708210951x7c8c9605wa31d8994965801a8@mail.gmail.com>
Date: Tue, 21 Aug 2007 09:51:24 -0700
From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com>
To: "Heiko Wundram (Beenic)" <wundram@beenic.net>
In-Reply-To: <200708211228.02044.wundram@beenic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200708211228.02044.wundram@beenic.net>
Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>
Subject: Re: Binding RFCOMM sockets
X-BeenThere: freebsd-bluetooth@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Using Bluetooth in FreeBSD environments
	<freebsd-bluetooth.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth>, 
	<mailto:freebsd-bluetooth-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bluetooth>
List-Post: <mailto:freebsd-bluetooth@freebsd.org>
List-Help: <mailto:freebsd-bluetooth-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth>, 
	<mailto:freebsd-bluetooth-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2007 16:51:26 -0000

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