From owner-freebsd-bluetooth@FreeBSD.ORG Tue Aug 21 10:57:21 2007 Return-Path: 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 D031016A420 for ; Tue, 21 Aug 2007 10:57:21 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 95C0E13C459 for ; Tue, 21 Aug 2007 10:57:21 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.37] (a89-182-6-212.net-htp.de [89.182.6.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id E7588A44529 for ; Tue, 21 Aug 2007 12:25:10 +0200 (CEST) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: "freebsd-bluetooth@freebsd.org" Date: Tue, 21 Aug 2007 12:28:01 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708211228.02044.wundram@beenic.net> Subject: Binding RFCOMM sockets X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 10:57:21 -0000 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 From owner-freebsd-bluetooth@FreeBSD.ORG Tue Aug 21 16:51:26 2007 Return-Path: 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 ; 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 ; 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 ; 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: Date: Tue, 21 Aug 2007 09:51:24 -0700 From: "Maksim Yevmenkin" To: "Heiko Wundram (Beenic)" 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From owner-freebsd-bluetooth@FreeBSD.ORG Wed Aug 22 21:06:32 2007 Return-Path: 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 C48AC16A418 for ; Wed, 22 Aug 2007 21:06:32 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smarthost01.eng.net (smarthost01.eng.net [213.130.146.173]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7B913C4A7 for ; Wed, 22 Aug 2007 21:06:32 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from netmail01.eng.net ([213.130.128.38] helo=rya-online.net) by smarthost01.eng.net with smtp (Exim 4.62) (envelope-from ) id 1INuxw-0000MJ-8S; Wed, 22 Aug 2007 19:30:10 +0100 Received: (nullmailer pid 1645 invoked by uid 1000); Tue, 21 Aug 2007 20:09:53 -0000 Date: Tue, 21 Aug 2007 21:09:52 +0100 (BST) To: "Heiko Wundram \(Beenic\)" In-Reply-To: References: <200708211228.02044.wundram@beenic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1187726992.986273.1438.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2007 21:06:32 -0000 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 From owner-freebsd-bluetooth@FreeBSD.ORG Wed Aug 22 21:21:54 2007 Return-Path: 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 34C5C16A41A for ; Wed, 22 Aug 2007 21:21:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id ADC9C13C48A for ; Wed, 22 Aug 2007 21:21:53 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so265574nfb for ; Wed, 22 Aug 2007 14:21:52 -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=B6HyiTmTogXUkG8joVI0eMTBaiCpJG0QhdZVTEoK/5IL/q0LbZhhyx4qv29DPe2ZXUv4mx1Oc5AhKQ6QxFdaZMUaPbuO8HkTh0GnWR4na/IjdtMFMDpjC3aoEKGZluV6mJuz/c876Ly0AjGrNWM/aZvNoRrNrLOZlugwgZ9egtE= 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=KrZBKLBSklYvv/Y+pb69qL3ROKR04x+Tn394umnADld+Ap5Ia2FAtVR7S+PICefIYnThBRKVagUSQsn+08La/vgWkEdSeKUBVAEJVGsQg5I80EIKAQ5VcYM8iKY5t4hVU0QAGSjTSQZi2bbQ4lYAZKb6htFETJjyJ91xqMXhPCk= Received: by 10.86.81.8 with SMTP id e8mr797136fgb.1187817711874; Wed, 22 Aug 2007 14:21:51 -0700 (PDT) Received: by 10.86.25.9 with HTTP; Wed, 22 Aug 2007 14:21:51 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 14:21:51 -0700 From: "Maksim Yevmenkin" To: "Iain Hibbert" In-Reply-To: <1187726992.986273.1438.nullmailer@galant.ukfsn.org> 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> <1187726992.986273.1438.nullmailer@galant.ukfsn.org> Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2007 21:21:54 -0000 On 8/21/07, Iain Hibbert 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 From owner-freebsd-bluetooth@FreeBSD.ORG Thu Aug 23 08:59:23 2007 Return-Path: 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 40E5D16A418 for ; Thu, 23 Aug 2007 08:59:23 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0125C13C49D for ; Thu, 23 Aug 2007 08:59:22 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.37] (a89-182-19-209.net-htp.de [89.182.19.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id 17BF3A44529; Thu, 23 Aug 2007 10:56:24 +0200 (CEST) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: "Maksim Yevmenkin" Date: Thu, 23 Aug 2007 10:59:17 +0200 User-Agent: KMail/1.9.7 References: <200708211228.02044.wundram@beenic.net> <1187726992.986273.1438.nullmailer@galant.ukfsn.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708231059.19779.wundram@beenic.net> Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2007 08:59:23 -0000 Am Mittwoch 22 August 2007 23:21:51 schrieb Maksim Yevmenkin: > On 8/21/07, Iain Hibbert 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