From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 00:22:16 2009 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 F3E861065672 for ; Wed, 4 Feb 2009 00:22:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by mx1.freebsd.org (Postfix) with ESMTP id A70418FC12 for ; Wed, 4 Feb 2009 00:22:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so1423948ele.13 for ; Tue, 03 Feb 2009 16:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SRqhDpuAv2hTmGZMVl8sAsGNhTjlwSs2+SWvpcnYNDA=; b=oUbXl0HS5YU9YrN1olrE2NMwvGAzjX7wDe7KGIYioNngL96lo6BN4In3iGNIl2pKUU 9a7CkAa6I7X4+I78e+rHr5yCJlsqWwIhPcDrr0WbPwvdKR3qFyebjmpv3gAQ2GV8q8IA DwZbgws27hQMbAkEV65/XFjPpH5rhJ4iEAIfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IFLErJryFhXSD6X6Zn6RA4QWn226ZinadxsBdWINsCF52O/wTPwL5ppwPI/ggkSW6c AP6nWYws2mSJEHat1hSEWpDeFzVLeigjCzox8wXS/6+1GfjEte2MrA3mVKZ3M2z//seE vXElatBUTF7CD6WRctaHAugveFY5TS68PHphE= MIME-Version: 1.0 Received: by 10.150.196.5 with SMTP id t5mr543136ybf.142.1233706935012; Tue, 03 Feb 2009 16:22:15 -0800 (PST) In-Reply-To: <4988DCCC.80201@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> Date: Tue, 3 Feb 2009 16:22:14 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 00:22:16 -0000 Alexander, [...] > Thanks for the good news and your work. I have managed to use by Qtek S200 > running WM 6.1 Internet Sharing service (NAP profile). It has worked just > out of the box. thanks for the report! > The only newbie problem I had is what to specify in -d argument. NetBSD > examples specifying adapter name there, while FreeBSD does not accepts this. > I have spent some time looking for my adapter BDADDR. well, it kinda does. you can edit /etc/bluetooth/hosts file and add your adapter's bd_addr there, i.e. 00:11:22:33:44:55 mydevice and then use -d mydevice with btpand(8). > PS: I have one small indirectly related, annoying problem. After some time > of being unused Qtek goes to some kind of sleep, which makes it not > responding on BT requests (both rfcomm and btpand), reporting "No route to > host". After several retries or just by running l2ping and waiting for 3-5 > seconds it successfully wakes up and working, but it makes using it a bit > annoying. Is there any known workaround for it? it depends. i'm guessing qtek device is probably putting idle connection into 'sniff' or 'hold' (or even 'park') mode to conserve battery life. you should be able to see what is going by running hcidump. in any case, it should be possible to add something that 'tickles' connection once in a short while to prevent it from going completely idle. it will drain the battery faster though. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 01:09:47 2009 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 91489106566B for ; Wed, 4 Feb 2009 01:09:47 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 10B698FC0C for ; Wed, 4 Feb 2009 01:09:46 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233433864; Wed, 04 Feb 2009 02:09:44 +0200 Message-ID: <4988DCCC.80201@mavhome.dp.ua> Date: Wed, 04 Feb 2009 02:09:48 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> In-Reply-To: <1233365217.00068654.1233354838@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 01:09:47 -0000 Maksim Yevmenkin wrote: > i'm pleased to announce that i've just imported btpand(8) daemon from > netbsd. this daemon provides support for NAP, GN and PANU profiles. > i've briefly tested it with a couple of PAN-enabled devices (i.e. my > windows-xp laptop and old hp ipaq 1940 running windows ce 4.20). Thanks for the good news and your work. I have managed to use by Qtek S200 running WM 6.1 Internet Sharing service (NAP profile). It has worked just out of the box. The only newbie problem I had is what to specify in -d argument. NetBSD examples specifying adapter name there, while FreeBSD does not accepts this. I have spent some time looking for my adapter BDADDR. PS: I have one small indirectly related, annoying problem. After some time of being unused Qtek goes to some kind of sleep, which makes it not responding on BT requests (both rfcomm and btpand), reporting "No route to host". After several retries or just by running l2ping and waiting for 3-5 seconds it successfully wakes up and working, but it makes using it a bit annoying. Is there any known workaround for it? PPS: Thanks again! -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 01:13:11 2009 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 DDD28106564A for ; Wed, 4 Feb 2009 01:13:11 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0648FC08 for ; Wed, 4 Feb 2009 01:13:11 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233439045; Wed, 04 Feb 2009 03:13:10 +0200 Message-ID: <4988EBAC.3080202@mavhome.dp.ua> Date: Wed, 04 Feb 2009 03:13:16 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 01:13:12 -0000 Maksim Yevmenkin wrote: >> The only newbie problem I had is what to specify in -d argument. NetBSD >> examples specifying adapter name there, while FreeBSD does not accepts this. >> I have spent some time looking for my adapter BDADDR. > > well, it kinda does. you can edit /etc/bluetooth/hosts file and add > your adapter's bd_addr there, i.e. > > 00:11:22:33:44:55 mydevice > > and then use -d mydevice with btpand(8). I have done exactly the same, it just was not intuitive and differs from NetBSD as I understood it. It was probably the first time when I needed to know my adapter BDADDR. >> PS: I have one small indirectly related, annoying problem. After some time >> of being unused Qtek goes to some kind of sleep, which makes it not >> responding on BT requests (both rfcomm and btpand), reporting "No route to >> host". After several retries or just by running l2ping and waiting for 3-5 >> seconds it successfully wakes up and working, but it makes using it a bit >> annoying. Is there any known workaround for it? > > it depends. i'm guessing qtek device is probably putting idle > connection into 'sniff' or 'hold' (or even 'park') mode to conserve > battery life. you should be able to see what is going by running > hcidump. in any case, it should be possible to add something that > 'tickles' connection once in a short while to prevent it from going > completely idle. it will drain the battery faster though. It does not happens when connection is alive, only when connection establishes. So may be there some kind of timeout can be tuned, or device can be forcefully woken up in some other way? One more minor fact. Unlike rfcomm_pppd I haven't found an option to run btpand in foreground to track connection status. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 01:32:00 2009 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 9E1821065670 for ; Wed, 4 Feb 2009 01:32:00 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by mx1.freebsd.org (Postfix) with ESMTP id 46E208FC19 for ; Wed, 4 Feb 2009 01:31:59 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk14 with SMTP id 14so2422737gxk.19 for ; Tue, 03 Feb 2009 17:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rxiji0hXNL0nswIUB7596HJTjx+7yHXxafBCfDpQ/7k=; b=qQ4IbBKgKlb1z1Q4hLQi4MQUg8tvYRdzrVFliMomKZRCX8hR7DZqudt+pmLpbF9bW9 J9EBxjjj+k+v9D7bRDbRGN5rFC9vz/ThhMWdFj7Qq3ELOdHvVx5O6nrRt3RwQR59vLZf IwYi37HunI4xFTa6iVm0j4+ZHZVN5OXyUzW4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kcOrX87EnNEljc92ptE4URCx0udG662hV7mO9vzoT9G2T9ZpHXWYybPsaj8USMp7j1 OdtBjBTW60WO1UmxuRvhjDQEuu7bRIB+qQFmACSXmbCMNFaL9mXYa3Em008pVNE31p5x lfweyCrDSIWKLq7aqF+t3uLa4nY5Pkr7tOnhg= MIME-Version: 1.0 Received: by 10.151.13.9 with SMTP id q9mr118812ybi.202.1233711119617; Tue, 03 Feb 2009 17:31:59 -0800 (PST) In-Reply-To: <4988EBAC.3080202@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> Date: Tue, 3 Feb 2009 17:31:59 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 01:32:01 -0000 On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >>> >>> The only newbie problem I had is what to specify in -d argument. NetBSD >>> examples specifying adapter name there, while FreeBSD does not accepts >>> this. >>> I have spent some time looking for my adapter BDADDR. >> >> well, it kinda does. you can edit /etc/bluetooth/hosts file and add >> your adapter's bd_addr there, i.e. >> >> 00:11:22:33:44:55 mydevice >> >> and then use -d mydevice with btpand(8). > > I have done exactly the same, it just was not intuitive and differs from > NetBSD as I understood it. It was probably the first time when I needed to > know my adapter BDADDR. and what name would you like to use? ubt0? something else? dont forget we dont create nodes under /dev for bluetooth devices. just netgraph nodes. i have plan to implement libhci (a-la linux bluez etc.) shim eventually :) if someone feels like beating me to it, i would certainly not object to it :) btw, obtaining bdaddr is really easy. in 99.9% cases (where there is only one bluetooth device connected to the system) 'hccontrol read_bd_addr' will do the trick :) >>> PS: I have one small indirectly related, annoying problem. After some >>> time >>> of being unused Qtek goes to some kind of sleep, which makes it not >>> responding on BT requests (both rfcomm and btpand), reporting "No route >>> to >>> host". After several retries or just by running l2ping and waiting for >>> 3-5 >>> seconds it successfully wakes up and working, but it makes using it a bit >>> annoying. Is there any known workaround for it? >> >> it depends. i'm guessing qtek device is probably putting idle >> connection into 'sniff' or 'hold' (or even 'park') mode to conserve >> battery life. you should be able to see what is going by running >> hcidump. in any case, it should be possible to add something that >> 'tickles' connection once in a short while to prevent it from going >> completely idle. it will drain the battery faster though. > > It does not happens when connection is alive, only when connection > establishes. So may be there some kind of timeout can be tuned, or device > can be forcefully woken up in some other way? oh, i misunderstood then. are you saying that initial connection setup is slow? if so, then i'm guessing your qtek device is maybe missing initial paging attempts. either this or something else is going on. when you do inquiry what do Page Scan Rep. Mode Page Scan Period Mode Page Scan Mode say for your qtek device? you can try to increase page timeout, i.e. 'hccontrol write_page_timeout' if your qtek device is timing out during initial page attempt (default timeout is ~5sec). in any case hcidump that shows the problem would be a good start. > One more minor fact. Unlike rfcomm_pppd I haven't found an option to run > btpand in foreground to track connection status. because there isn't one :) can be added though :) please feel free to send in the patches :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 02:07:15 2009 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 4FC29106566B for ; Wed, 4 Feb 2009 02:07:15 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3158FC0C for ; Wed, 4 Feb 2009 02:07:14 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233441485; Wed, 04 Feb 2009 04:07:13 +0200 Message-ID: <4988F857.5080407@mavhome.dp.ua> Date: Wed, 04 Feb 2009 04:07:19 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 02:07:15 -0000 Maksim Yevmenkin wrote: > On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>>> The only newbie problem I had is what to specify in -d argument. NetBSD >>>> examples specifying adapter name there, while FreeBSD does not accepts >>>> this. >>>> I have spent some time looking for my adapter BDADDR. >>> well, it kinda does. you can edit /etc/bluetooth/hosts file and add >>> your adapter's bd_addr there, i.e. >>> >>> 00:11:22:33:44:55 mydevice >>> >>> and then use -d mydevice with btpand(8). >> I have done exactly the same, it just was not intuitive and differs from >> NetBSD as I understood it. It was probably the first time when I needed to >> know my adapter BDADDR. > > and what name would you like to use? ubt0? something else? dont forget > we dont create nodes under /dev for bluetooth devices. just netgraph > nodes. i have plan to implement libhci (a-la linux bluez etc.) shim > eventually :) if someone feels like beating me to it, i would > certainly not object to it :) Actually yes, ubt0. System reports it on boot, it is reported to the peered devices in hostname and NetBSD does so. IMHO it is not a bad choice from user's point of view. Does actually this binding really necessary? rfcomm somehow works without it. > btw, obtaining bdaddr is really easy. in 99.9% cases (where there is > only one bluetooth device connected to the system) 'hccontrol > read_bd_addr' will do the trick :) Indeed. But general number of BT tools, daemons and their options just making me sad. >>>> PS: I have one small indirectly related, annoying problem. After some >>>> time >>>> of being unused Qtek goes to some kind of sleep, which makes it not >>>> responding on BT requests (both rfcomm and btpand), reporting "No route >>>> to >>>> host". After several retries or just by running l2ping and waiting for >>>> 3-5 >>>> seconds it successfully wakes up and working, but it makes using it a bit >>>> annoying. Is there any known workaround for it? >>> it depends. i'm guessing qtek device is probably putting idle >>> connection into 'sniff' or 'hold' (or even 'park') mode to conserve >>> battery life. you should be able to see what is going by running >>> hcidump. in any case, it should be possible to add something that >>> 'tickles' connection once in a short while to prevent it from going >>> completely idle. it will drain the battery faster though. >> It does not happens when connection is alive, only when connection >> establishes. So may be there some kind of timeout can be tuned, or device >> can be forcefully woken up in some other way? > > oh, i misunderstood then. are you saying that initial connection setup > is slow? if so, then i'm guessing your qtek device is maybe missing > initial paging attempts. either this or something else is going on. > when you do inquiry what do > > Page Scan Rep. Mode > Page Scan Period Mode > Page Scan Mode Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 > say for your qtek device? you can try to increase page timeout, i.e. > 'hccontrol write_page_timeout' if your qtek device is timing out > during initial page attempt (default timeout is ~5sec). > > in any case hcidump that shows the problem would be a good start. First run: < HCI Command: Create Connection(0x01|0x0005) plen 13 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connect Complete(0x03) plen 11 btpand[4215]: NAP: Host is down Second run: < HCI Command: Create Connection(0x01|0x0005) plen 13 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connect Complete(0x03) plen 11 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x00b0 > HCI Event: Command Complete(0x0e) plen 6 > HCI Event: Max Slots Change(0x1b) plen 3 btpand[4222]: Searching for NAP service at 00:12:d1:38:4a:fa btpand[4222]: Found PSM 15 for service NAP btpand[4222]: Opening connection to service 0x1116 at 00:12:d1:38:4a:fa btpand[4222]: channel_open: (fd#4) btpand[4222]: Using interface tap10 with addr 00:00:d9:fb:48:16 btpand[4222]: channel_open: (fd#5) -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 15:58:34 2009 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 AE29D106566B for ; Wed, 4 Feb 2009 15:58:34 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACBB8FC16 for ; Wed, 4 Feb 2009 15:58:34 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LUjpH-0007Na-Uh; Wed, 04 Feb 2009 15:38:08 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28252-05; Wed, 4 Feb 2009 15:38:07 +0000 (GMT) Received: from [10.35.255.231] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LUjpD-0007Ms-Tt; Wed, 04 Feb 2009 15:38:07 +0000 Received: (nullmailer pid 530 invoked by uid 1000); Wed, 04 Feb 2009 14:57:43 -0000 Date: Wed, 4 Feb 2009 14:57:43 +0000 (GMT) To: Alexander Motin In-Reply-To: <4988F857.5080407@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233759463.493208.401.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 15:58:35 -0000 On Wed, 4 Feb 2009, Alexander Motin wrote: [relating to -d device] > Does actually this binding really necessary? rfcomm somehow works without it. This binding is used (in original version) to set the tap interface address to be the same as the bdaddr. I did consider allowing to use it without setting that but then ethernet packets are being transmitted with a source address that is not the bdaddr. Now, IIRC it would seem that the spec allows this, but my windows mobile device (for instance) fails to route packets back to the computer. there are a couple of ways around this I could see 1. skip the bdaddr_any(local_bdaddr) check while validating the command line options, but add something to set it if it is unset. That would be the easiest option I guess but you need to be able to find the device with the best route to remote (could be first device, could be we already have a connection to remote device - I don't know what FreeBSD provides here?) 2. perform 'address rewriting' on ethernet packets. Actually this is not that difficult to do and I had it going during testing (when receiving packets, if the source address is the same as the remote bdaddr, or the ethernet tap address, set it to NULL. When sending, if the source is NULL, use the local bdaddr or ethernet tap address.) This also allows a single btpand instance to straddle multiple controllers but I thought it might be better to keep it simple in the beginning. the fact of it requiring the commandline argument at first I prefer - because its always possible to relax a requirement but not to tighten one up :) iain From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 15:58:35 2009 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 6D18B106566C for ; Wed, 4 Feb 2009 15:58:35 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id E395A8FC12 for ; Wed, 4 Feb 2009 15:58:34 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LUjpf-0007Nw-3Y; Wed, 04 Feb 2009 15:38:31 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28252-06; Wed, 4 Feb 2009 15:38:30 +0000 (GMT) Received: from [10.35.255.231] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LUjpd-0007Nq-AM; Wed, 04 Feb 2009 15:38:30 +0000 Received: (nullmailer pid 460 invoked by uid 1000); Wed, 04 Feb 2009 15:10:29 -0000 Date: Wed, 4 Feb 2009 15:10:29 +0000 (GMT) To: Alexander Motin In-Reply-To: <4988EBAC.3080202@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233760229.131312.504.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 15:58:35 -0000 On Wed, 4 Feb 2009, Alexander Motin wrote: > One more minor fact. Unlike rfcomm_pppd I haven't found an option to run > btpand in foreground to track connection status. what would you like to accomplish? I made some effort for it to not detach until the setup is complete, but it kind of needs to then in order for 'connection up' activities to commence (eg proceeding to run dhclient).. at least on my machine I have logging turned up and do get some shutdown messages on the console when it detaches. I have not run it as a NAP or GN so I'm not sure if anything needs to happen when connections come and go there but I thought maybe not as its similar to plugging other computers in the other side of a switch. iain From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 15:58:35 2009 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 ABA79106564A for ; Wed, 4 Feb 2009 15:58:35 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD248FC1A for ; Wed, 4 Feb 2009 15:58:35 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LUjoj-0007Lz-BW; Wed, 04 Feb 2009 15:37:33 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28252-01; Wed, 4 Feb 2009 15:37:33 +0000 (GMT) Received: from [10.35.255.231] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LUjoh-0007Lr-PP; Wed, 04 Feb 2009 15:37:32 +0000 Received: (nullmailer pid 387 invoked by uid 1000); Wed, 04 Feb 2009 14:41:59 -0000 Date: Wed, 4 Feb 2009 14:41:59 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233758519.360141.162.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: libhci (was Re: pan profile support in freebsd) 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, 04 Feb 2009 15:58:36 -0000 On Tue, 3 Feb 2009, Maksim Yevmenkin wrote: > i have plan to implement libhci (a-la linux bluez etc.) shim > eventually :) if someone feels like beating me to it, i would > certainly not object to it :) what api would you envisage? iain From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 17:47:13 2009 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 64958106566C for ; Wed, 4 Feb 2009 17:47:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 197578FC19 for ; Wed, 4 Feb 2009 17:47:12 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1059109yxb.13 for ; Wed, 04 Feb 2009 09:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b/XAf7A+yIKvZuKksPTvZA0ziwezUGGMfuBpLPbECXE=; b=uktsv4bFkatGC3pN0DaVdPdMlm2BFpvhfRvBXQcDgwnCVXEbyHn1nPMKwiasZKhV9c gN4ULT7Wuro1oeTLY0i7QgYPMNOtmDDSrSRcp6bLEyopiY6AbFiO8nrqYgn/ITPImhND HogaPIlcHJYm4gO3z3PtZbLFjGj6+FQZrlAfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cGU+uTIaD3tW1b//RvSZJnG1aNDtKknyq/FJ2Fog1xReuUeyVybN+Iw9YHcscbiq3d ALakCFSyN8VreNXzcdbnPeS3tZ56givWm2J8tkn1JLST0gTzBp5j/ppjOgIfTEyMbOng hTN5Y0XhqNZiQS0Jyne8gfVwwpSTwb4WJGq70= MIME-Version: 1.0 Received: by 10.151.12.1 with SMTP id p1mr1219214ybi.4.1233769632357; Wed, 04 Feb 2009 09:47:12 -0800 (PST) In-Reply-To: <4988F857.5080407@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> Date: Wed, 4 Feb 2009 09:47:12 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 17:47:13 -0000 [...] >> and what name would you like to use? ubt0? something else? dont forget >> we dont create nodes under /dev for bluetooth devices. just netgraph >> nodes. i have plan to implement libhci (a-la linux bluez etc.) shim >> eventually :) if someone feels like beating me to it, i would >> certainly not object to it :) > > Actually yes, ubt0. System reports it on boot, it is reported to the peered > devices in hostname and NetBSD does so. IMHO it is not a bad choice from > user's point of view. ok, i will look into it. this will definitely be after hci shims. enumerating all the radios in the system is the job for hci shim. there is something already in hccontrol(8) to do that, but i do not want to duplicate the code and rather move it into hci shim. > Does actually this binding really necessary? rfcomm somehow works without > it. please see Iain's response :) i knew he would chime in :) thanks Iain! and, yes, i suspected that it would be something related to mac addresses on virtual ethernet interface. i do not have a copy of spec handy, but i recall something about setting mac address to be the same as radio's bd_addr. dont remember if it was a requirement or more of a guideline. in any case, i like Iain's suggestion to rewrite mac addresses on the fly. i would have done it this way. also, i think, nap server should just act as ethernet hub, i.e. forward everything everywhere. after all, nap is supposed to be like local ethernet network :) >> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is >> only one bluetooth device connected to the system) 'hccontrol >> read_bd_addr' will do the trick :) > > Indeed. But general number of BT tools, daemons and their options just > making me sad. i'm not sure how to read that :) there is, like, less than 10 bluetooth related daemons in total. each has, like, may be 10 options. compare this to the number of options ls(1) has :) not sure what could possibly make you sad here. if you feel that the documentation is not adequate, please feel free to fix it :) [....] >>> It does not happens when connection is alive, only when connection >>> establishes. So may be there some kind of timeout can be tuned, or device >>> can be forcefully woken up in some other way? >> >> oh, i misunderstood then. are you saying that initial connection setup >> is slow? if so, then i'm guessing your qtek device is maybe missing >> initial paging attempts. either this or something else is going on. >> when you do inquiry what do >> >> Page Scan Rep. Mode >> Page Scan Period Mode >> Page Scan Mode > > Page Scan Rep. Mode: 0x1 > Page Scan Period Mode: 00 > Page Scan Mode: 00 ah, so your device wants to use r1 page scan repetition mode. off-the-shelf dongles usually use r2 mode. that is basically defines how radio will scan for page/attempt to page. its basically baseband/link manager (aka firmware on the device itself - not stack) >> say for your qtek device? you can try to increase page timeout, i.e. >> 'hccontrol write_page_timeout' if your qtek device is timing out >> during initial page attempt (default timeout is ~5sec). >> >> in any case hcidump that shows the problem would be a good start. > > First run: > > < HCI Command: Create Connection(0x01|0x0005) plen 13 >> HCI Event: Command Status(0x0f) plen 4 >> HCI Event: Connect Complete(0x03) plen 11 > > btpand[4215]: NAP: Host is down > > Second run: > > < HCI Command: Create Connection(0x01|0x0005) plen 13 >> HCI Event: Command Status(0x0f) plen 4 >> HCI Event: Connect Complete(0x03) plen 11 > < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 > < ACL data: handle 0x000b flags 0x02 dlen 12 > L2CAP(s): Connect req: psm 1 scid 0x00b0 >> HCI Event: Command Complete(0x0e) plen 6 >> HCI Event: Max Slots Change(0x1b) plen 3 > > btpand[4222]: Searching for NAP service at 00:12:d1:38:4a:fa > btpand[4222]: Found PSM 15 for service NAP > btpand[4222]: Opening connection to service 0x1116 at 00:12:d1:38:4a:fa > btpand[4222]: channel_open: (fd#4) > btpand[4222]: Using interface tap10 with addr 00:00:d9:fb:48:16 > btpand[4222]: channel_open: (fd#5) right, next time please either user '-x' or '-w' option to hcidump. in this case, it does not matter, since, in failure case, clearly nothing happens after connection_complete event, so we could not even establish baseband connection (i can not see the error code on the dump but i'm guessing its page timeout). like i said, you could try to increase page timeout of your local radio, or, you could try to find if your device has knobs that would allow to set radio's scan window and scan interval. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 18:00:20 2009 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 3C488106566B for ; Wed, 4 Feb 2009 18:00:20 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id E65898FC16 for ; Wed, 4 Feb 2009 18:00:19 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1064993ywe.13 for ; Wed, 04 Feb 2009 10:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zlI95izaS96pWtYVRWYFt+kwehq9RlKA/nwUO3WDLuA=; b=HRA+YYirPf983xZwSk/DpkvwGWMchPJdXTYScxuocDo9DtQDQVzEg/ejL+RL8OVmIr 9lqOagRlaS/K/7ByqH2dihR+/Xsdvee3brt7MgbZv2rnpEFV78fepSIHAQV900L5w4XZ NQYn4BgA7KkEMfljnaQ68Z2xSkMmBuPlCMx4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VjeFXms8sZYLOMlrMPhYny9u5I5mXlpxyhzczQVdZH9yDatKaKIS805TCe22JJqYcr /d3bsv6S2HYz9xgzCnlrTSXu8vo5i0tSPenW84MvYoV2d9Y8++zfC7QjT8J7vk5Ef2jx AUvGR7U6Ycv8majenTZ7+hXSkoOWNzRSY6vQM= MIME-Version: 1.0 Received: by 10.231.14.141 with SMTP id g13mr924699iba.38.1233770418879; Wed, 04 Feb 2009 10:00:18 -0800 (PST) In-Reply-To: <1233758519.360141.162.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> Date: Wed, 4 Feb 2009 10:00:18 -0800 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: libhci (was Re: pan profile support in freebsd) 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, 04 Feb 2009 18:00:20 -0000 On Wed, Feb 4, 2009 at 6:41 AM, Iain Hibbert wrote: > On Tue, 3 Feb 2009, Maksim Yevmenkin wrote: > >> i have plan to implement libhci (a-la linux bluez etc.) shim >> eventually :) if someone feels like beating me to it, i would >> certainly not object to it :) > > what api would you envisage? i was thinking about doing most of the http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=lib/hci.c;hb=1fa3750cb917358a6fb6bc718429c9000dd61ab3 starting from int hci_inquiry(...) and all the way down to the end of the file :) basically map dev_id to unit numbers, i.e. dev_id 0 is "ubt0" node, etc. i'm a bit concerned that if we follow linux too closely someone might throw a hissy fit about bsd stealing linux's code and not using gpl :) so we have to tread lightly here, imo :) and, btw, i do not think i'm going to create a separate libhci for this. existing libbluetooth is perfectly fine. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 18:39:47 2009 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 CB53F10656D1 for ; Wed, 4 Feb 2009 18:39:46 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAFF8FC29 for ; Wed, 4 Feb 2009 18:39:45 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233553126; Wed, 04 Feb 2009 20:39:45 +0200 Message-ID: <4989E0F7.3020301@mavhome.dp.ua> Date: Wed, 04 Feb 2009 20:39:51 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Iain Hibbert References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> In-Reply-To: <1233760229.131312.504.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 18:39:48 -0000 Iain Hibbert wrote: > On Wed, 4 Feb 2009, Alexander Motin wrote: > >> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run >> btpand in foreground to track connection status. > > what would you like to accomplish? For example, to initiate reconnect on connection failure. Sure it can be done in many other ways, but running in foreground seems to be usual practice for many places, like ppp. > I made some effort for it to not detach until the setup is complete, but > it kind of needs to then in order for 'connection up' activities to > commence (eg proceeding to run dhclient).. at least on my machine I have > logging turned up and do get some shutdown messages on the console when it > detaches. I think dhclient, for example, could be run via devd when interface comes up, alike to normal Ethernet. Not sure TAP supports devd not, but I think it could be fixed. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 19:07:58 2009 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 BADF1106566B for ; Wed, 4 Feb 2009 19:07:58 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 37D398FC0C for ; Wed, 4 Feb 2009 19:07:57 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233555387; Wed, 04 Feb 2009 21:07:57 +0200 Message-ID: <4989E793.2030503@mavhome.dp.ua> Date: Wed, 04 Feb 2009 21:08:03 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Iain Hibbert References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <1233759463.493208.401.nullmailer@galant.ukfsn.org> In-Reply-To: <1233759463.493208.401.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 19:07:59 -0000 Iain Hibbert wrote: > On Wed, 4 Feb 2009, Alexander Motin wrote: > [relating to -d device] >> Does actually this binding really necessary? rfcomm somehow works without it. > > This binding is used (in original version) to set the tap interface > address to be the same as the bdaddr. I did consider allowing to use it > without setting that but then ethernet packets are being transmitted with > a source address that is not the bdaddr. Now, IIRC it would seem that the > spec allows this, but my windows mobile device (for instance) fails to > route packets back to the computer. > > there are a couple of ways around this I could see > > 1. skip the bdaddr_any(local_bdaddr) check while validating the command > line options, but add something to set it if it is unset. That would > be the easiest option I guess but you need to be able to find the > device with the best route to remote (could be first device, could be > we already have a connection to remote device - I don't know what > FreeBSD provides here?) Have no idea how routing expected to work in case of several BT adapters, this it is interesting, but I think quite rare case. I think it could be good to be implemented alike to usual inet connectivity, when unbinded accepting connection sets remotely requested IP as it's local, and outgoing connecting socket choose local IP using routing table. I am not sure if terms or routing applicable here, but at least we have some mesh of peered devices and if there is several peered, we could choose one of using some algorithm, depending on load or order, or just round-robin. > 2. perform 'address rewriting' on ethernet packets. Actually this is not > that difficult to do and I had it going during testing (when receiving > packets, if the source address is the same as the remote bdaddr, or the > ethernet tap address, set it to NULL. When sending, if the source is > NULL, use the local bdaddr or ethernet tap address.) This also allows > a single btpand instance to straddle multiple controllers but I thought > it might be better to keep it simple in the beginning. I don't very like idea of rewriting. It looks like a hack and may confuse somebody. Also if it works as plain Ethernet, then you will probably have to rewrite ARP for IPv4 and it's equivalent for IPv6, and something other for other protocols. It could become a permanent pain. > the fact of it requiring the commandline argument at first I prefer - > because its always possible to relax a requirement but not to tighten one > up :) -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 19:27:44 2009 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 9234D1065670 for ; Wed, 4 Feb 2009 19:27:44 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0FBBE8FC1D for ; Wed, 4 Feb 2009 19:27:43 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233557231; Wed, 04 Feb 2009 21:27:43 +0200 Message-ID: <4989EC35.80502@mavhome.dp.ua> Date: Wed, 04 Feb 2009 21:27:49 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 19:27:44 -0000 Maksim Yevmenkin wrote: >> Does actually this binding really necessary? rfcomm somehow works without >> it. > > please see Iain's response :) i knew he would chime in :) thanks Iain! > > and, yes, i suspected that it would be something related to mac > addresses on virtual ethernet interface. i do not have a copy of spec > handy, but i recall something about setting mac address to be the same > as radio's bd_addr. dont remember if it was a requirement or more of a > guideline. > > in any case, i like Iain's suggestion to rewrite mac addresses on the > fly. i would have done it this way. also, i think, nap server should > just act as ethernet hub, i.e. forward everything everywhere. after > all, nap is supposed to be like local ethernet network :) Hmm. Working like an Ethernet hub also means that every single hub port (in our case every single point-to-point BT link) may transmit packets from different source MAC addresses, that can't be equal to BT adapter address. So or I don't understand your example, or something is wrong here. >>> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is >>> only one bluetooth device connected to the system) 'hccontrol >>> read_bd_addr' will do the trick :) >> Indeed. But general number of BT tools, daemons and their options just >> making me sad. > > i'm not sure how to read that :) there is, like, less than 10 > bluetooth related daemons in total. each has, like, may be 10 options. > compare this to the number of options ls(1) has :) not sure what could > possibly make you sad here. if you feel that the documentation is not > adequate, please feel free to fix it :) 10 daemons is understood, as BT is not that simple and IP stack also have many different tools. But anyway having about 70 defined and undocumented arguments of hccontrol alone, one of which should be used for such basic thing as getting local btaddr, are not looking so funny for anybody who are not BT guru. May be writing of some man page with some BT basics to cross reference that basic tools could help. Or just better cross reference existing pages. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 19:32:06 2009 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 7A80E1065693 for ; Wed, 4 Feb 2009 19:32:06 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 395478FC1C for ; Wed, 4 Feb 2009 19:32:06 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LUnTd-0002Di-F8; Wed, 04 Feb 2009 19:32:01 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08296-10; Wed, 4 Feb 2009 19:32:01 +0000 (GMT) Received: from [10.35.255.231] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LUnTa-0002DP-I2; Wed, 04 Feb 2009 19:32:00 +0000 Received: (nullmailer pid 2681 invoked by uid 1000); Wed, 04 Feb 2009 19:31:48 -0000 Date: Wed, 4 Feb 2009 19:31:48 +0000 (GMT) To: Alexander Motin In-Reply-To: <4989E0F7.3020301@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> <4989E0F7.3020301@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233775908.626621.2538.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 19:32:06 -0000 On Wed, 4 Feb 2009, Alexander Motin wrote: > Iain Hibbert wrote: > > On Wed, 4 Feb 2009, Alexander Motin wrote: > > > > > One more minor fact. Unlike rfcomm_pppd I haven't found an option to run > > > btpand in foreground to track connection status. > > > > what would you like to accomplish? > > For example, to initiate reconnect on connection failure. Sure it can be done > in many other ways, but running in foreground seems to be usual practice for > many places, like ppp. > > > I made some effort for it to not detach until the setup is complete, but > > it kind of needs to then in order for 'connection up' activities to > > commence (eg proceeding to run dhclient).. at least on my machine I have > > logging turned up and do get some shutdown messages on the console when it > > detaches. > > I think dhclient, for example, could be run via devd when interface comes up, > alike to normal Ethernet. Not sure TAP supports devd not, but I think it could > be fixed. One thing that I have in mind is to make btpand shutdown the tap interface when exiting (as it marks it up when starting). Would that make it possible to use devd to trigger a reconnect if desired? I think its better to have a "event->action" model rather than hang it all together with scripts. iain From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 19:53:31 2009 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 3578A1065718 for ; Wed, 4 Feb 2009 19:53:31 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id A40218FC14 for ; Wed, 4 Feb 2009 19:53:29 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233559493; Wed, 04 Feb 2009 21:53:28 +0200 Message-ID: <4989F23F.8040102@mavhome.dp.ua> Date: Wed, 04 Feb 2009 21:53:35 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Iain Hibbert References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> <4989E0F7.3020301@mavhome.dp.ua> <1233775908.626621.2538.nullmailer@galant.ukfsn.org> In-Reply-To: <1233775908.626621.2538.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 19:53:32 -0000 Iain Hibbert wrote: > On Wed, 4 Feb 2009, Alexander Motin wrote: > >> Iain Hibbert wrote: >>> On Wed, 4 Feb 2009, Alexander Motin wrote: >>> >>>> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run >>>> btpand in foreground to track connection status. >>> what would you like to accomplish? >> For example, to initiate reconnect on connection failure. Sure it can be done >> in many other ways, but running in foreground seems to be usual practice for >> many places, like ppp. >> >>> I made some effort for it to not detach until the setup is complete, but >>> it kind of needs to then in order for 'connection up' activities to >>> commence (eg proceeding to run dhclient).. at least on my machine I have >>> logging turned up and do get some shutdown messages on the console when it >>> detaches. >> I think dhclient, for example, could be run via devd when interface comes up, >> alike to normal Ethernet. Not sure TAP supports devd not, but I think it could >> be fixed. > > One thing that I have in mind is to make btpand shutdown the tap interface > when exiting (as it marks it up when starting). Would that make it > possible to use devd to trigger a reconnect if desired? I think its > better to have a "event->action" model rather than hang it all together > with scripts. It already removes UP status from interface, so there is action which could be tracked by devd. No need to destroy interface if it was not created by you. But from other side devd is more complicated and system-wide case that some trivial custom shell script, so I would prefer to use it just for something common, like running dhclient with adding something like ifconfig_tap1="DHCP" to rc.conf alike to normal Ethernets. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 20:02:35 2009 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 3BF71106564A for ; Wed, 4 Feb 2009 20:02:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id E482C8FC08 for ; Wed, 4 Feb 2009 20:02:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1100564ywe.13 for ; Wed, 04 Feb 2009 12:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cESM/YtUm1hMywSeOJOd1vJygCRWWKs713TQf/vHAMY=; b=KEBkU9hPZv+n/w7II/QJAzADMWL/cRJUKP/yWZu5eJmnrsE4lvF2FlWXRDXI/5ltnX WJmg/hKnmqM5P1dbcJJotuToAFWXmmz8uPwy+h20TiOKyfEBIrPypB/IRIvRK33F3Atq KEHt6Eo2as9Zb+Iu/rtbx7TcuRvPunuBHfso0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sMQGzJo4g5FwbnhktGnYU7HjS+svghdd80fEvQos62jY96LfZ/Joco00cpXoSeBr5W TRCkcFaoot2pFKlPXeASMJdvmdz9yTCFDVeX3zqQThl9g389IHZbqr+62nqYGSoSoaqG hMXyYuVY+hSICTa2vzLT2zfcSGVW0hcxndBBw= MIME-Version: 1.0 Received: by 10.231.32.70 with SMTP id b6mr948989ibd.33.1233777753863; Wed, 04 Feb 2009 12:02:33 -0800 (PST) In-Reply-To: <4989EC35.80502@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> Date: Wed, 4 Feb 2009 12:02:33 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 20:02:35 -0000 On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >>> >>> Does actually this binding really necessary? rfcomm somehow works without >>> it. >> >> please see Iain's response :) i knew he would chime in :) thanks Iain! >> >> and, yes, i suspected that it would be something related to mac >> addresses on virtual ethernet interface. i do not have a copy of spec >> handy, but i recall something about setting mac address to be the same >> as radio's bd_addr. dont remember if it was a requirement or more of a >> guideline. >> >> in any case, i like Iain's suggestion to rewrite mac addresses on the >> fly. i would have done it this way. also, i think, nap server should >> just act as ethernet hub, i.e. forward everything everywhere. after >> all, nap is supposed to be like local ethernet network :) > > Hmm. Working like an Ethernet hub also means that every single hub port (in > our case every single point-to-point BT link) may transmit packets from > different source MAC addresses, that can't be equal to BT adapter address. > So or I don't understand your example, or something is wrong here. why do you think it is wrong? logically all the radios are on the same virtual ethernet network. i think the only issue here is that apparently some clients are picky about src mac address and that complicates the case when nap server has multiple radios. [...] >>> Indeed. But general number of BT tools, daemons and their options just >>> making me sad. >> >> i'm not sure how to read that :) there is, like, less than 10 >> bluetooth related daemons in total. each has, like, may be 10 options. >> compare this to the number of options ls(1) has :) not sure what could >> possibly make you sad here. if you feel that the documentation is not >> adequate, please feel free to fix it :) > > 10 daemons is understood, as BT is not that simple and IP stack also have > many different tools. But anyway having about 70 defined and undocumented > arguments of hccontrol alone, one of which should be used for such basic > thing as getting local btaddr, are not looking so funny for anybody who are > not BT guru. May be writing of some man page with some BT basics to cross > reference that basic tools could help. Or just better cross reference > existing pages. oh, please :) man hccontrol(8) gives you all the commands. it also tells you to use 'help ' to get more information. also help for each command is taken directly from the bluetooth specification. i'm not sure how much more documentation can we put here. there are also man pages for ng_hci(4) and ng_l2cap(4). that is already so much more information than you can ever get on vast majority of bluetooth enabled gadgets. oh, and btw, users are not even supposed to know/touch any of this stuff. so if your bluetooth gadget does not work - you sh*t out of luck for the most of the time :) in ideal world, everything should just work. in real world, like everything that has to do with rf, sometimes it doesn't :) i agree, documentation could always be better, and i repeatedly asked for help here. i do not know why, but for whatever reason people prefer to put stuff on their private webpages/blogs/forums/etc. instead of just saying "hey, i had this problem and here is how i fixed it. wouldn't it be nice if you could document this in man page/handbook. btw, here is the patch." thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 20:13:18 2009 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 86F5F1065674 for ; Wed, 4 Feb 2009 20:13:18 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 00FDA8FC1B for ; Wed, 4 Feb 2009 20:13:17 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233561111; Wed, 04 Feb 2009 22:13:16 +0200 Message-ID: <4989F6E3.9020702@mavhome.dp.ua> Date: Wed, 04 Feb 2009 22:13:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 20:13:18 -0000 Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>>> Does actually this binding really necessary? rfcomm somehow works without >>>> it. >>> please see Iain's response :) i knew he would chime in :) thanks Iain! >>> >>> and, yes, i suspected that it would be something related to mac >>> addresses on virtual ethernet interface. i do not have a copy of spec >>> handy, but i recall something about setting mac address to be the same >>> as radio's bd_addr. dont remember if it was a requirement or more of a >>> guideline. >>> >>> in any case, i like Iain's suggestion to rewrite mac addresses on the >>> fly. i would have done it this way. also, i think, nap server should >>> just act as ethernet hub, i.e. forward everything everywhere. after >>> all, nap is supposed to be like local ethernet network :) >> Hmm. Working like an Ethernet hub also means that every single hub port (in >> our case every single point-to-point BT link) may transmit packets from >> different source MAC addresses, that can't be equal to BT adapter address. >> So or I don't understand your example, or something is wrong here. > > why do you think it is wrong? logically all the radios are on the same > virtual ethernet network. i think the only issue here is that > apparently some clients are picky about src mac address and that > complicates the case when nap server has multiple radios. You have told that NAP server works as hub. So, as I have understood, it retransmits upstream traffic back down to all/some clients. So, it transmits packets with MAC addresses of other clients via it's BT adapter. So, source MAC address will not match his BDADDR. Or server is an exception, which can violate the rule of equal addresses? -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 20:27:02 2009 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 2E20A106567C for ; Wed, 4 Feb 2009 20:27:02 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id DE3A08FC2A for ; Wed, 4 Feb 2009 20:27:01 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LUoKq-0002xR-M6; Wed, 04 Feb 2009 20:27:00 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11341-02; Wed, 4 Feb 2009 20:27:00 +0000 (GMT) Received: from [10.35.255.231] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LUoKn-0002xM-Co; Wed, 04 Feb 2009 20:27:00 +0000 Received: (nullmailer pid 3011 invoked by uid 1000); Wed, 04 Feb 2009 20:26:47 -0000 Date: Wed, 4 Feb 2009 20:26:47 +0000 (GMT) To: Alexander Motin In-Reply-To: <4989F23F.8040102@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> <4989E0F7.3020301@mavhome.dp.ua> <1233775908.626621.2538.nullmailer@galant.ukfsn.org> <4989F23F.8040102@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233779207.215414.2993.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 20:27:03 -0000 On Wed, 4 Feb 2009, Alexander Motin wrote: > Iain Hibbert wrote: > > One thing that I have in mind is to make btpand shutdown the tap interface > > when exiting (as it marks it up when starting). Would that make it > > possible to use devd to trigger a reconnect if desired? I think its > > better to have a "event->action" model rather than hang it all together > > with scripts. > > It already removes UP status from interface, so there is action which could be > tracked by devd. Ah, I see. That is a difference in FreeBSD tap(4) device and I wondered about that but will put it on my list to see if its desireable for NetBSD, rather than modifying btpand to do the same. > No need to destroy interface if it was not created by you. no, thats all automatic > But from other side devd is more complicated and system-wide case that some > trivial custom shell script, so I would prefer to use it just for something > common, like running dhclient with adding something like ifconfig_tap1="DHCP" > to rc.conf alike to normal Ethernets. There may be trouble there because network is started before bluetooth, but adding a 'stay in foreground' switch should not be difficult. iain From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 21:17:07 2009 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 6DEE51065675 for ; Wed, 4 Feb 2009 21:17:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2066F8FC0A for ; Wed, 4 Feb 2009 21:17:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1116896yxb.13 for ; Wed, 04 Feb 2009 13:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l5sIF+ovnBdi76XOCBNyQ2XCgQavW/CBtLs9vntWHJc=; b=ERCNrh4NMsNE5P+kzrR7CivWL8W+1pCqL71q9+fEXOclpLXM9K9ZlpRK8xHAJqe8eU j6VGdq6tlJcCoQHKmljyXIUnbs4QIl0zObIKH5J8jUW58+ENbCh8409k3XDI5BzC7lru gi/6Grh/3SoJylapXXpzc6cn58B3jWeUCac4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Kz1R8UwxPhNIC7MplGBu/SfXOSjYudY6t12agY8LEmVG5nZPLRQqVlju5Kz9recE7a 6DWDEOoj+6dTN/cvUBrwqZysuT1F9AvOb8/0eSa5dPF/W+GXoICYYYIHS7C10I/IAEZO LCDlHGmndf89HejbWsEGQ32QOPltgdoNtPQT8= MIME-Version: 1.0 Received: by 10.231.20.5 with SMTP id d5mr961568ibb.25.1233782226028; Wed, 04 Feb 2009 13:17:06 -0800 (PST) In-Reply-To: <4989F6E3.9020702@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> Date: Wed, 4 Feb 2009 13:17:05 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 21:17:07 -0000 On Wed, Feb 4, 2009 at 12:13 PM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >> >> On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin >> wrote: >>> >>> Maksim Yevmenkin wrote: >>>>> >>>>> Does actually this binding really necessary? rfcomm somehow works >>>>> without >>>>> it. >>>> >>>> please see Iain's response :) i knew he would chime in :) thanks Iain! >>>> >>>> and, yes, i suspected that it would be something related to mac >>>> addresses on virtual ethernet interface. i do not have a copy of spec >>>> handy, but i recall something about setting mac address to be the same >>>> as radio's bd_addr. dont remember if it was a requirement or more of a >>>> guideline. >>>> >>>> in any case, i like Iain's suggestion to rewrite mac addresses on the >>>> fly. i would have done it this way. also, i think, nap server should >>>> just act as ethernet hub, i.e. forward everything everywhere. after >>>> all, nap is supposed to be like local ethernet network :) >>> >>> Hmm. Working like an Ethernet hub also means that every single hub port >>> (in >>> our case every single point-to-point BT link) may transmit packets from >>> different source MAC addresses, that can't be equal to BT adapter >>> address. >>> So or I don't understand your example, or something is wrong here. >> >> why do you think it is wrong? logically all the radios are on the same >> virtual ethernet network. i think the only issue here is that >> apparently some clients are picky about src mac address and that >> complicates the case when nap server has multiple radios. > > You have told that NAP server works as hub. So, as I have understood, it > retransmits upstream traffic back down to all/some clients. So, it transmits > packets with MAC addresses of other clients via it's BT adapter. So, source > MAC address will not match his BDADDR. Or server is an exception, which can > violate the rule of equal addresses? well, i think we have a disconnect here ;) you see, bnep strips ethernet header completely and replaces it with one of the bnep ethernet headers. your options basically are 1) bnep ethernet header that has both src and dst "mac addresses" (that is both src and dst radio bd_addr's) 2) bnep ethernet header that has only src "mac address" (that is src radio bd_addr only) 3) bnep ethernet header that has only dst "mac address" (that is dst radio bd_addr only) (2) and (3) are basically short forms of (1) and used when it is possible to figure out missing dst or src "mac address" (that is bd_addr really) because there is a directly "attached" rf link. in other words, if i know that you are the final recipient of the packet and i have a direct rf link to you, i'm not going to bother to set dst "mac address" in bnep packet, because you obviously know your "mac address" (bd_addr). or if i generate a packet and i have a direct rf link to you, i'm not going to set src "mac address" (that is bd_addr really) because you know that this packet can only come from me and you already know my "mac address" (bd_addr) so, imo, there is nothing really prevents us from using multiple local radios. also mac address on tap interface is really does not matter, because its get stripped anyway. that is unless tap interface checks dst mac address and make sure it matches (like freebsd does) before passing packet up the stack. if any case, setting promisc. flag on interface will fix it. the only mess here is that arp responses for local tap interface will contain mac address of tap interface and not bd_addr of (one of the) local radio(s). i say, who cares, as long as its properly encapsulated into bnep, imo, it should work. so even if both endpoints have a direct rf link, it will look like they are not. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 21:51:23 2009 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 A74DD106566C for ; Wed, 4 Feb 2009 21:51:23 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0548F8FC0A for ; Wed, 4 Feb 2009 21:51:22 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233566828; Wed, 04 Feb 2009 23:51:21 +0200 Message-ID: <498A0DDF.1050605@mavhome.dp.ua> Date: Wed, 04 Feb 2009 23:51:27 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 21:51:24 -0000 Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 12:13 PM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>> On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin >>> wrote: >>>> Maksim Yevmenkin wrote: >>>>>> Does actually this binding really necessary? rfcomm somehow works >>>>>> without >>>>>> it. >>>>> please see Iain's response :) i knew he would chime in :) thanks Iain! >>>>> >>>>> and, yes, i suspected that it would be something related to mac >>>>> addresses on virtual ethernet interface. i do not have a copy of spec >>>>> handy, but i recall something about setting mac address to be the same >>>>> as radio's bd_addr. dont remember if it was a requirement or more of a >>>>> guideline. >>>>> >>>>> in any case, i like Iain's suggestion to rewrite mac addresses on the >>>>> fly. i would have done it this way. also, i think, nap server should >>>>> just act as ethernet hub, i.e. forward everything everywhere. after >>>>> all, nap is supposed to be like local ethernet network :) >>>> Hmm. Working like an Ethernet hub also means that every single hub port >>>> (in >>>> our case every single point-to-point BT link) may transmit packets from >>>> different source MAC addresses, that can't be equal to BT adapter >>>> address. >>>> So or I don't understand your example, or something is wrong here. >>> why do you think it is wrong? logically all the radios are on the same >>> virtual ethernet network. i think the only issue here is that >>> apparently some clients are picky about src mac address and that >>> complicates the case when nap server has multiple radios. >> You have told that NAP server works as hub. So, as I have understood, it >> retransmits upstream traffic back down to all/some clients. So, it transmits >> packets with MAC addresses of other clients via it's BT adapter. So, source >> MAC address will not match his BDADDR. Or server is an exception, which can >> violate the rule of equal addresses? > > well, i think we have a disconnect here ;) you see, bnep strips > ethernet header completely and replaces it with one of the bnep > ethernet headers. your options basically are > > 1) bnep ethernet header that has both src and dst "mac addresses" > (that is both src and dst radio bd_addr's) > > 2) bnep ethernet header that has only src "mac address" (that is src > radio bd_addr only) > > 3) bnep ethernet header that has only dst "mac address" (that is dst > radio bd_addr only) > > (2) and (3) are basically short forms of (1) and used when it is > possible to figure out missing dst or src "mac address" (that is > bd_addr really) because there is a directly "attached" rf link. > > in other words, if i know that you are the final recipient of the > packet and i have a direct rf link to you, i'm not going to bother to > set dst "mac address" in bnep packet, because you obviously know your > "mac address" (bd_addr). > > or > > if i generate a packet and i have a direct rf link to you, i'm not > going to set src "mac address" (that is bd_addr really) because you > know that this packet can only come from me and you already know my > "mac address" (bd_addr) Thanks for the explanation, I have got it. Looking into specification I see there is even four header formats: no addresses, source, dest and source+dest. As I understand it's just a form of header compression. As soon as each side knows address of the peer it can compress MAC address if it matches to respective BDADDR. And that's all. > so, imo, there is nothing really prevents us from using multiple local > radios. also mac address on tap interface is really does not matter, > because its get stripped anyway. that is unless tap interface checks > dst mac address and make sure it matches (like freebsd does) before > passing packet up the stack. if any case, setting promisc. flag on > interface will fix it. the only mess here is that arp responses for > local tap interface will contain mac address of tap interface and not > bd_addr of (one of the) local radio(s). i say, who cares, as long as > its properly encapsulated into bnep, imo, it should work. so even if > both endpoints have a direct rf link, it will look like they are not. I still think we should not do such hacks. As I understand there is OK to bridge completely unrelated Ethernet traffic via BNEP link. As soon as MAC addresses does not match to BDADDRs, packets should just be transmitter with full uncompressed Ethernet header. We should keep TAP MAC address equal to BDADDR just as much as possible to maximally benefit from header compression. But if we have single TAP interface on server, which handles several links via different adapters, I understand it should be fine to just choose one of BDADDRs as MAC address to be completely honest to everybody. If there is only one adapter, then all headers will be compressed, if there is several - only part of them. Am I right? -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 22:27:54 2009 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 BF30D1065697 for ; Wed, 4 Feb 2009 22:27:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 72CC08FC23 for ; Wed, 4 Feb 2009 22:27:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1133562yxb.13 for ; Wed, 04 Feb 2009 14:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k2lKWM0+ImPAQoUUvwkW//6N5zGc33f5nBWwB1Heb60=; b=Qn8mKf4ofIdQg6SRKuo7nZxoQl1hNURAL/0hECZjI/ZERmdzQ4AMD7zaB4uRgLpu4z JRK4oG8t5t2AlEs5TeIYI/jaGQr5arPl471qtWmbA2oxo6nor4JjZXnyUxu3ZpJw8tw/ 8KmUAnsye5/K1wyRGF3fy4kaVWTRdLAWH53VQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f7Hyn/mpstKqjksqv7FxLK+X0xE+mfcCnAObnsejw4YNgVxALJb8T+G9BvsVvte9tj qwEEFCGolM8hE7EUF+xDdqs7R/Um81kHZt48D36+zz4IsgJ2Eh/sPll5QubSbV9MfJdc YhF1O67aPDmI/gr1+xwWDZhqH105DtoTmeL2w= MIME-Version: 1.0 Received: by 10.150.98.18 with SMTP id v18mr3535853ybb.231.1233786473766; Wed, 04 Feb 2009 14:27:53 -0800 (PST) In-Reply-To: <498A0DDF.1050605@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> Date: Wed, 4 Feb 2009 14:27:53 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 22:27:55 -0000 On Wed, Feb 4, 2009 at 1:51 PM, Alexander Motin wrote: [...] >>>>> Hmm. Working like an Ethernet hub also means that every single hub port >>>>> (in >>>>> our case every single point-to-point BT link) may transmit packets from >>>>> different source MAC addresses, that can't be equal to BT adapter >>>>> address. >>>>> So or I don't understand your example, or something is wrong here. >>>> >>>> why do you think it is wrong? logically all the radios are on the same >>>> virtual ethernet network. i think the only issue here is that >>>> apparently some clients are picky about src mac address and that >>>> complicates the case when nap server has multiple radios. >>> >>> You have told that NAP server works as hub. So, as I have understood, it >>> retransmits upstream traffic back down to all/some clients. So, it >>> transmits >>> packets with MAC addresses of other clients via it's BT adapter. So, >>> source >>> MAC address will not match his BDADDR. Or server is an exception, which >>> can >>> violate the rule of equal addresses? >> >> well, i think we have a disconnect here ;) you see, bnep strips >> ethernet header completely and replaces it with one of the bnep >> ethernet headers. your options basically are >> >> 1) bnep ethernet header that has both src and dst "mac addresses" >> (that is both src and dst radio bd_addr's) >> >> 2) bnep ethernet header that has only src "mac address" (that is src >> radio bd_addr only) >> >> 3) bnep ethernet header that has only dst "mac address" (that is dst >> radio bd_addr only) >> >> (2) and (3) are basically short forms of (1) and used when it is >> possible to figure out missing dst or src "mac address" (that is >> bd_addr really) because there is a directly "attached" rf link. >> >> in other words, if i know that you are the final recipient of the >> packet and i have a direct rf link to you, i'm not going to bother to >> set dst "mac address" in bnep packet, because you obviously know your >> "mac address" (bd_addr). >> >> or >> >> if i generate a packet and i have a direct rf link to you, i'm not >> going to set src "mac address" (that is bd_addr really) because you >> know that this packet can only come from me and you already know my >> "mac address" (bd_addr) > > Thanks for the explanation, I have got it. Looking into specification I see > there is even four header formats: no addresses, source, dest and > source+dest. oh yes, i forgot about "no src, no dst" packet :) its been a while since i looked at bnep specification :) so, yes, "no src, no dst" is used when both packet originator and receiver's radios are directly connected via rf link. > As I understand it's just a form of header compression. As soon as each side > knows address of the peer it can compress MAC address if it matches to > respective BDADDR. And that's all. exactly. i must admit that saving up to 14 bytes on relatively slow bluetooth link does not exactly strike me as a huge win :) but what do i know anyway :) >> so, imo, there is nothing really prevents us from using multiple local >> radios. also mac address on tap interface is really does not matter, >> because its get stripped anyway. that is unless tap interface checks >> dst mac address and make sure it matches (like freebsd does) before >> passing packet up the stack. if any case, setting promisc. flag on >> interface will fix it. the only mess here is that arp responses for >> local tap interface will contain mac address of tap interface and not >> bd_addr of (one of the) local radio(s). i say, who cares, as long as >> its properly encapsulated into bnep, imo, it should work. so even if >> both endpoints have a direct rf link, it will look like they are not. > > I still think we should not do such hacks. As I understand there is OK to > bridge completely unrelated Ethernet traffic via BNEP link. As soon as MAC > addresses does not match to BDADDRs, packets should just be transmitter with > full uncompressed Ethernet header. We should keep TAP MAC address equal to > BDADDR just as much as possible to maximally benefit from header > compression. But if we have single TAP interface on server, which handles > several links via different adapters, I understand it should be fine to just > choose one of BDADDRs as MAC address to be completely honest to everybody. > If there is only one adapter, then all headers will be compressed, if there > is several - only part of them. > > Am I right? well, yes and no. somehow you need to map multiple local bd_addr to either one bd_addr or completely different mac address on tap interface. somehow i think that having completely different mac address on tap interface and map all the local bd_addr's to it makes it cleaner. even if we have to transfer 6 extra bytes in bnep header. i like the ability to bind to wildcard address, it allows us to run bluetooth servers even if there are no bluetooth radios connected to the system. for example, i run sdpd, hcsecd etc. on my laptop always. when i need, i simply plug my usb bluetooth dongle it - presto - it all works. magic! :) if you bind to a particular radio, then you tied to it. cant do anything before radio is present and cant do anything after radio is gone. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 22:40:34 2009 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 EE7461065670 for ; Wed, 4 Feb 2009 22:40:33 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 255EA8FC1E for ; Wed, 4 Feb 2009 22:40:32 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233569993; Thu, 05 Feb 2009 00:40:31 +0200 Message-ID: <498A1966.4030600@mavhome.dp.ua> Date: Thu, 05 Feb 2009 00:40:38 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 22:40:34 -0000 Maksim Yevmenkin wrote: >> As I understand it's just a form of header compression. As soon as each side >> knows address of the peer it can compress MAC address if it matches to >> respective BDADDR. And that's all. > > exactly. i must admit that saving up to 14 bytes on relatively slow > bluetooth link does not exactly strike me as a huge win :) but what do > i know anyway :) > >>> so, imo, there is nothing really prevents us from using multiple local >>> radios. also mac address on tap interface is really does not matter, >>> because its get stripped anyway. that is unless tap interface checks >>> dst mac address and make sure it matches (like freebsd does) before >>> passing packet up the stack. if any case, setting promisc. flag on >>> interface will fix it. the only mess here is that arp responses for >>> local tap interface will contain mac address of tap interface and not >>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>> its properly encapsulated into bnep, imo, it should work. so even if >>> both endpoints have a direct rf link, it will look like they are not. >> I still think we should not do such hacks. As I understand there is OK to >> bridge completely unrelated Ethernet traffic via BNEP link. As soon as MAC >> addresses does not match to BDADDRs, packets should just be transmitter with >> full uncompressed Ethernet header. We should keep TAP MAC address equal to >> BDADDR just as much as possible to maximally benefit from header >> compression. But if we have single TAP interface on server, which handles >> several links via different adapters, I understand it should be fine to just >> choose one of BDADDRs as MAC address to be completely honest to everybody. >> If there is only one adapter, then all headers will be compressed, if there >> is several - only part of them. >> >> Am I right? > > well, yes and no. somehow you need to map multiple local bd_addr to > either one bd_addr or completely different mac address on tap > interface. somehow i think that having completely different mac > address on tap interface and map all the local bd_addr's to it makes > it cleaner. even if we have to transfer 6 extra bytes in bnep header. > i like the ability to bind to wildcard address, it allows us to run > bluetooth servers even if there are no bluetooth radios connected to > the system. for example, i run sdpd, hcsecd etc. on my laptop always. > when i need, i simply plug my usb bluetooth dongle it - presto - it > all works. magic! :) if you bind to a particular radio, then you tied > to it. cant do anything before radio is present and cant do anything > after radio is gone. If there is no any radio present yet, you can just choose any random MAC address for TAP and transfer it via BNEP later. You will loose 6 bytes per packet due to addresses mismatch, but it should work. By doing unconditional translation of TAP MAC address into BDADDR, you will make impossible bridging between Bluetooth and local network, which is interesting, as can be used, for example, as cheap and low power WiFi alternative. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 23:00:50 2009 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 2FADF106575B for ; Wed, 4 Feb 2009 23:00:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by mx1.freebsd.org (Postfix) with ESMTP id BAC018FC1A for ; Wed, 4 Feb 2009 23:00:49 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk14 with SMTP id 14so3000884gxk.19 for ; Wed, 04 Feb 2009 15:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eP+mKdx6KCFs3EavlZFE1nsqXna5SIa3CMEF/wTudSk=; b=DzfEsPO7LwO7YbGKUEXQh6weti4cyymJOKFkFJvfkwDVHlLPrAfF/VbMyHC1YJYwBl NT5xG1WzjxkH8VkUPVc4P2Z7e9aCIMVsg/u4Qw5YV55co+ublt13fCgYTP0Pa3ghVQOu Xj2CPW/ni10zyppNKrP6KrSIlLIv+YLwVGtB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CDMdF6t9Mmx0ukWEzDzxJgX9jteTrw1YKj1pMKuwitSaWEJbeJQtMzAI/Gupp4jIfh JKTJCg9RyWSuCqqXRErtqm8xQtHA1Y6WDbl3Qkv0L09V5r0UeOQWH0bN5M1bH+LA+//U 5n1s0wyZTyMj+swbRTazFr1tXrNJec3m7xwqY= MIME-Version: 1.0 Received: by 10.151.48.20 with SMTP id a20mr3510548ybk.179.1233788449106; Wed, 04 Feb 2009 15:00:49 -0800 (PST) In-Reply-To: <498A1966.4030600@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> Date: Wed, 4 Feb 2009 15:00:49 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 04 Feb 2009 23:00:50 -0000 [...] >>>> so, imo, there is nothing really prevents us from using multiple local >>>> radios. also mac address on tap interface is really does not matter, >>>> because its get stripped anyway. that is unless tap interface checks >>>> dst mac address and make sure it matches (like freebsd does) before >>>> passing packet up the stack. if any case, setting promisc. flag on >>>> interface will fix it. the only mess here is that arp responses for >>>> local tap interface will contain mac address of tap interface and not >>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>> its properly encapsulated into bnep, imo, it should work. so even if >>>> both endpoints have a direct rf link, it will look like they are not. >>> >>> I still think we should not do such hacks. As I understand there is OK to >>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>> MAC >>> addresses does not match to BDADDRs, packets should just be transmitter >>> with >>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>> to >>> BDADDR just as much as possible to maximally benefit from header >>> compression. But if we have single TAP interface on server, which handles >>> several links via different adapters, I understand it should be fine to >>> just >>> choose one of BDADDRs as MAC address to be completely honest to >>> everybody. >>> If there is only one adapter, then all headers will be compressed, if >>> there >>> is several - only part of them. >>> >>> Am I right? >> >> well, yes and no. somehow you need to map multiple local bd_addr to >> either one bd_addr or completely different mac address on tap >> interface. somehow i think that having completely different mac >> address on tap interface and map all the local bd_addr's to it makes >> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >> i like the ability to bind to wildcard address, it allows us to run >> bluetooth servers even if there are no bluetooth radios connected to >> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >> when i need, i simply plug my usb bluetooth dongle it - presto - it >> all works. magic! :) if you bind to a particular radio, then you tied >> to it. cant do anything before radio is present and cant do anything >> after radio is gone. > > If there is no any radio present yet, you can just choose any random MAC > address for TAP and transfer it via BNEP later. You will loose 6 bytes per > packet due to addresses mismatch, but it should work. By doing unconditional tap is already getting "randomly" selected mac address by default. > translation of TAP MAC address into BDADDR, you will make impossible > bridging between Bluetooth and local network, which is interesting, as can > be used, for example, as cheap and low power WiFi alternative. huh? please explain why. i think if you want to put your nap (wireless) clients onto the same wired lan you might have on your nap server you will have to do bridging no matter what. otherwise your wired clients will not be able to talk to your nap (wireless) clients. and, btw, if i were to do such a setup in real world, i would _never_ever_ use bridging unless i _absolutely_ had to. its just soooo much easier/cleaner/etc. to put nap (wireless) clients onto a separate subnet and use ip routing. as far as wifi alternative goes, its not really going to fly, imo. range is too short, speed is too slow, and it can only do 7 clients at the same time. does not scale at all :( maybe ok for home, but i yet to see a laptop/desktop that has bluetooth and does not have wifi :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 06:37:02 2009 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 93E1F106564A for ; Thu, 5 Feb 2009 06:37:02 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C69958FC23 for ; Thu, 5 Feb 2009 06:37:01 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233592800; Thu, 05 Feb 2009 08:37:00 +0200 Message-ID: <498A8912.9050208@mavhome.dp.ua> Date: Thu, 05 Feb 2009 08:37:06 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 05 Feb 2009 06:37:02 -0000 Maksim Yevmenkin wrote: > [...] > >>>>> so, imo, there is nothing really prevents us from using multiple local >>>>> radios. also mac address on tap interface is really does not matter, >>>>> because its get stripped anyway. that is unless tap interface checks >>>>> dst mac address and make sure it matches (like freebsd does) before >>>>> passing packet up the stack. if any case, setting promisc. flag on >>>>> interface will fix it. the only mess here is that arp responses for >>>>> local tap interface will contain mac address of tap interface and not >>>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>>> its properly encapsulated into bnep, imo, it should work. so even if >>>>> both endpoints have a direct rf link, it will look like they are not. >>>> I still think we should not do such hacks. As I understand there is OK to >>>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>>> MAC >>>> addresses does not match to BDADDRs, packets should just be transmitter >>>> with >>>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>>> to >>>> BDADDR just as much as possible to maximally benefit from header >>>> compression. But if we have single TAP interface on server, which handles >>>> several links via different adapters, I understand it should be fine to >>>> just >>>> choose one of BDADDRs as MAC address to be completely honest to >>>> everybody. >>>> If there is only one adapter, then all headers will be compressed, if >>>> there >>>> is several - only part of them. >>>> >>>> Am I right? >>> well, yes and no. somehow you need to map multiple local bd_addr to >>> either one bd_addr or completely different mac address on tap >>> interface. somehow i think that having completely different mac >>> address on tap interface and map all the local bd_addr's to it makes >>> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >>> i like the ability to bind to wildcard address, it allows us to run >>> bluetooth servers even if there are no bluetooth radios connected to >>> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >>> when i need, i simply plug my usb bluetooth dongle it - presto - it >>> all works. magic! :) if you bind to a particular radio, then you tied >>> to it. cant do anything before radio is present and cant do anything >>> after radio is gone. >> If there is no any radio present yet, you can just choose any random MAC >> address for TAP and transfer it via BNEP later. You will loose 6 bytes per >> packet due to addresses mismatch, but it should work. By doing unconditional > > tap is already getting "randomly" selected mac address by default. > >> translation of TAP MAC address into BDADDR, you will make impossible >> bridging between Bluetooth and local network, which is interesting, as can >> be used, for example, as cheap and low power WiFi alternative. > > huh? please explain why. i think if you want to put your nap > (wireless) clients onto the same wired lan you might have on your nap > server you will have to do bridging no matter what. I just mean that bridging should be clean, you should pass LAN MAC addresses to Bluetooth directly without mapping to BDADDR and without compression. > otherwise your > wired clients will not be able to talk to your nap (wireless) clients. > and, btw, if i were to do such a setup in real world, i would > _never_ever_ use bridging unless i _absolutely_ had to. its just soooo > much easier/cleaner/etc. to put nap (wireless) clients onto a separate > subnet and use ip routing. > > as far as wifi alternative goes, its not really going to fly, imo. > range is too short, speed is too slow, and it can only do 7 clients at > the same time. does not scale at all :( maybe ok for home, but i yet > to see a laptop/desktop that has bluetooth and does not have wifi :) WiFi kills my PDA's battery in hour or even less and it's range and performance are not much different. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 08:38:58 2009 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 27897106566B for ; Thu, 5 Feb 2009 08:38:58 +0000 (UTC) (envelope-from florenzi@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id A72A38FC18 for ; Thu, 5 Feb 2009 08:38:57 +0000 (UTC) (envelope-from florenzi@gmail.com) Received: by ewy14 with SMTP id 14so164389ewy.19 for ; Thu, 05 Feb 2009 00:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:cc:subject :date:message-id:x-mailer:mime-version:content-language:content-type :content-transfer-encoding; bh=V07/tazoiwUVY1kA4fvQjTh2lq9fZplgJbjTZBsA3Tk=; b=pBxP/vaEsuRaQRO/sd/C7ZH/2V4jFTtVoNz3lDEHi0blItb/t+2oaUt6BCAgaFUXYw WuVM5LXse7NwBom5ZPLAkVU+lnQizEjwdniZJcYO2tH6Ikrg15AaESN3tUAtC+rXVruN YrD4gH1PMWhm1KxwpSy92OsbkJAjIVDiF7BEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:cc:subject:date:message-id:x-mailer:mime-version :content-language:content-type:content-transfer-encoding; b=aNHfeq6P86fNTMLbJRYKulbXt1dr4QmewfcTEr7gb5zl9UR9nzmzvwlvv8uwBYs48g IHCmblvN9yHumKLNIoJL22IdmU/8Xup633RvORYWp0TucQttRVE/Rt0D4T4LfxYGW8/N Tv5TYu7iUvt0wiYoAmgm1CRQYZgFNoIymGRko= Received: by 10.66.218.3 with SMTP id q3mr4278182ugg.24.1233821202375; Thu, 05 Feb 2009 00:06:42 -0800 (PST) Received: from ?172.30.153.243? ([41.208.11.180]) by mx.google.com with ESMTPS id x37sm4135359ugc.15.2009.02.05.00.06.38 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Feb 2009 00:06:41 -0800 (PST) From: "Federico Lorenzi" To: Alexander Motin Date: Thu, 5 Feb 2009 10:05:51 +0200 Message-ID: <3jnVJlwzBVVF.cHr1JC0S@smtp.gmail.com> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Federico Lorenzi List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 08:38:58 -0000 From: Alexander Motin Date: 05/02/2009 08:37 > WiFi kills my PDA's battery in hour or even less and it's range and = >performance are not much different. Interesting, in a few tests that I've done, my phone's (Nokia E66) WiFI is = significantly faster then Bluetooth, over 2MBps vs 70KBps, and range is far = greater, although I can vouch for the battery point. Cheers, Federico (Apologies if the formatting of this message is off) From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 14:47:19 2009 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 D023B1065674 for ; Thu, 5 Feb 2009 14:47:19 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9728FC18 for ; Thu, 5 Feb 2009 14:47:19 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LV5Va-0005V2-Lc; Thu, 05 Feb 2009 14:47:14 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21067-04; Thu, 5 Feb 2009 14:47:14 +0000 (GMT) Received: from [10.35.255.231] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LV5VY-0005Un-VM; Thu, 05 Feb 2009 14:47:14 +0000 Received: (nullmailer pid 1092 invoked by uid 1000); Thu, 05 Feb 2009 14:28:52 -0000 Date: Thu, 5 Feb 2009 14:28:52 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233844132.485077.7695.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 05 Feb 2009 14:47:20 -0000 On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > the system. for example, i run sdpd, hcsecd etc. on my laptop always. > when i need, i simply plug my usb bluetooth dongle it - presto - it > all works. magic! :) if you bind to a particular radio, then you tied > to it. cant do anything before radio is present and cant do anything > after radio is gone. You are [presumably] using devd to [notice that you inserted the dongle and] configure it anyway, there is no reason it can't start any other services you might require.. iain From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 14:47:22 2009 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 663FB106564A for ; Thu, 5 Feb 2009 14:47:22 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 24ADB8FC16 for ; Thu, 5 Feb 2009 14:47:22 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LV5Vh-0005VB-Em; Thu, 05 Feb 2009 14:47:21 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20932-10; Thu, 5 Feb 2009 14:47:21 +0000 (GMT) Received: from [10.35.255.231] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LV5Vf-0005V6-GX; Thu, 05 Feb 2009 14:47:21 +0000 Received: (nullmailer pid 8346 invoked by uid 1000); Thu, 05 Feb 2009 14:46:07 -0000 Date: Thu, 5 Feb 2009 14:46:07 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233845167.798942.24919.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: libhci 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, 05 Feb 2009 14:47:22 -0000 On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > int hci_inquiry(...) > > and all the way down to the end of the file :) basically map dev_id to > unit numbers, i.e. dev_id 0 is "ubt0" node, etc. Well, I really dislike that dev_id method to start with. But anyway, I think they are working on a new API that is somewhat higher level and more related to the dbus access. Also, I think that looking at that code, it was written in the beginning and is full of 'good ideas' that somebody might want to use, but in reality much of it has no need to be in a shared library. hci_inquiry() is perhaps the only function that really needs to have a generic cross platform API and it would be nice if it was oriented towards application level rather than tied to a lower layer implementation. I do not know what kind of API the Microsoft (Widcom?) or Apple stacks expose to applications for this, but I suspect they would be a better place to start. iain From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 17:51:29 2009 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 1C21D1065672 for ; Thu, 5 Feb 2009 17:51:29 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by mx1.freebsd.org (Postfix) with ESMTP id C0B5D8FC1C for ; Thu, 5 Feb 2009 17:51:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk14 with SMTP id 14so425467gxk.19 for ; Thu, 05 Feb 2009 09:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qT/nQbkt92VR2gk3+JE53yEvUNXfkVe9+ZzZsluNDJk=; b=eYSP8Bv1jT03hPhP5OEnhKhze1fQaqaEyGYFy5FdDGLQAdqEE39Ta0qRDt4JSG16O1 VdGMafDQozlYQkr89rnrMOn34wjywZHjOEu1BzpABQ4KnbLau+p1Z40gGWkhvW8MKub8 rsyef551Yh34sr0X9BE6PQ1WDhlYnovkqRHU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZSpCFU48v3tSgf0sKurh44Ay9mRc0S9/q29IF5K74e1sh8eSwV72W8aGJTedRn/VoF 1ODemPpMX9zTkHTBvh68R0ROSf/35rkPlv+NYgz5ZVtrhn+PtH9Uc7k2K8ReepYAIXsq HSjfsjHRcqEeZv8YuP5LmuIwz29jkSyb12HR8= MIME-Version: 1.0 Received: by 10.150.230.15 with SMTP id c15mr734802ybh.235.1233856288253; Thu, 05 Feb 2009 09:51:28 -0800 (PST) In-Reply-To: <498A8912.9050208@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> Date: Thu, 5 Feb 2009 09:51:28 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 05 Feb 2009 17:51:29 -0000 On Wed, Feb 4, 2009 at 10:37 PM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >> >> [...] >> >>>>>> so, imo, there is nothing really prevents us from using multiple local >>>>>> radios. also mac address on tap interface is really does not matter, >>>>>> because its get stripped anyway. that is unless tap interface checks >>>>>> dst mac address and make sure it matches (like freebsd does) before >>>>>> passing packet up the stack. if any case, setting promisc. flag on >>>>>> interface will fix it. the only mess here is that arp responses for >>>>>> local tap interface will contain mac address of tap interface and not >>>>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>>>> its properly encapsulated into bnep, imo, it should work. so even if >>>>>> both endpoints have a direct rf link, it will look like they are not. >>>>> >>>>> I still think we should not do such hacks. As I understand there is OK >>>>> to >>>>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>>>> MAC >>>>> addresses does not match to BDADDRs, packets should just be transmitter >>>>> with >>>>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>>>> to >>>>> BDADDR just as much as possible to maximally benefit from header >>>>> compression. But if we have single TAP interface on server, which >>>>> handles >>>>> several links via different adapters, I understand it should be fine to >>>>> just >>>>> choose one of BDADDRs as MAC address to be completely honest to >>>>> everybody. >>>>> If there is only one adapter, then all headers will be compressed, if >>>>> there >>>>> is several - only part of them. >>>>> >>>>> Am I right? >>>> >>>> well, yes and no. somehow you need to map multiple local bd_addr to >>>> either one bd_addr or completely different mac address on tap >>>> interface. somehow i think that having completely different mac >>>> address on tap interface and map all the local bd_addr's to it makes >>>> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >>>> i like the ability to bind to wildcard address, it allows us to run >>>> bluetooth servers even if there are no bluetooth radios connected to >>>> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >>>> when i need, i simply plug my usb bluetooth dongle it - presto - it >>>> all works. magic! :) if you bind to a particular radio, then you tied >>>> to it. cant do anything before radio is present and cant do anything >>>> after radio is gone. >>> >>> If there is no any radio present yet, you can just choose any random MAC >>> address for TAP and transfer it via BNEP later. You will loose 6 bytes >>> per >>> packet due to addresses mismatch, but it should work. By doing >>> unconditional >> >> tap is already getting "randomly" selected mac address by default. >> >>> translation of TAP MAC address into BDADDR, you will make impossible >>> bridging between Bluetooth and local network, which is interesting, as >>> can >>> be used, for example, as cheap and low power WiFi alternative. >> >> huh? please explain why. i think if you want to put your nap >> (wireless) clients onto the same wired lan you might have on your nap >> server you will have to do bridging no matter what. > > I just mean that bridging should be clean, you should pass LAN MAC addresses > to Bluetooth directly without mapping to BDADDR and without compression. i'm very confused now :) of course wired lan addresses will be passed to wireless clients as is, and, without any header compression. i'm talking about mapping local (to nap server) radio(s) bd_addr to local (to nap server) tap interface mac address. the nap server should never give any reason, to any directly attached wireless client, to use radio's bd_addr instead of tap interface mac address. in other words, the nap server should never use "no src" nor "no src, no dst" bnep headers. all locally (on the nap server) generated packets should always have src address set in bnep header and this src address should be the mac address set on the tap interface. on receiving side, the nap server should check "dst" address against the tap interface mac address and if they match, put packet into the tap device. also, assuming things are working correctly, the nap server should never get packets without "dst" set in bnep header. so, other than wasting 6 bytes, i do not see any downside to this approach. did i miss anything here? >> as far as wifi alternative goes, its not really going to fly, imo. >> range is too short, speed is too slow, and it can only do 7 clients at >> the same time. does not scale at all :( maybe ok for home, but i yet >> to see a laptop/desktop that has bluetooth and does not have wifi :) > > WiFi kills my PDA's battery in hour or even less and it's range and > performance are not much different. well, yes. bluetooth puts less of strain on a battery, but that's really because its low power and thus short range wireless link (inverse square law is really a bitch :) class 1 radio has a max power level of 1mW / 0dBm (rare - up to 1 meter) class 2 radio has a max power level of 2.5mW / 4dBm (most common - up to 10 meters) class 3 radio has a max power level of 100mW / 20dBm (un-common - up to 100 meters) wifi max permitted power levels vary from country to country, but you can (somewhat) compare it to bluetooth class 3 radio. of course you can play games with antennas and stuff, but that is another can of worms :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 17:55:44 2009 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 6A4D3106566B for ; Thu, 5 Feb 2009 17:55:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1504F8FC0C for ; Thu, 5 Feb 2009 17:55:43 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so168153ywe.13 for ; Thu, 05 Feb 2009 09:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q+OfHGzBGXYD47HlzP2PUL9XfXU3i/dP4TflNGhY7qQ=; b=t5HWWxU4w3MPg2S24sTBxJWcz81KR0WlEJ7l3k64t7JdiftVNTE2U5/OEWTnB72oVD kNQ9DedAvvaMDG3TnPc91B3nHqNShD53KIalA+jsx7pwPWfRGzDSCBO6aSwETTs/SQRM mjGK61CiJW0Azckpf1AoHdv7wzEUBS+AVWQOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jf3m54h+uagYubekdLM+clVMMLm9l3cYPAJ+UVTK9SjVHmgjcAFSEie8oKiLxUVOLe CglP9tobrUmSnPueZgYPezgvZKMEa89eDcAf2CUrRED3o4IXHZE9Tf6/vpOZp/UoGF24 /RHe6r8CPCzCHhdWrC0h1cuqvI4lzrrtckKOI= MIME-Version: 1.0 Received: by 10.150.181.7 with SMTP id d7mr739503ybf.229.1233856543298; Thu, 05 Feb 2009 09:55:43 -0800 (PST) In-Reply-To: <1233844132.485077.7695.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <1233844132.485077.7695.nullmailer@galant.ukfsn.org> Date: Thu, 5 Feb 2009 09:55:43 -0800 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 05 Feb 2009 17:55:44 -0000 On Thu, Feb 5, 2009 at 6:28 AM, Iain Hibbert wrote: > On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > >> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >> when i need, i simply plug my usb bluetooth dongle it - presto - it >> all works. magic! :) if you bind to a particular radio, then you tied >> to it. cant do anything before radio is present and cant do anything >> after radio is gone. > > You are [presumably] using devd to [notice that you inserted the dongle > and] configure it anyway, there is no reason it can't start any other > services you might require.. yes, devd is used to start stack when device is attached. yes, devd also can be used to start all the service daemons, but why makes things complicated? dealing with possible multiple failures (i.e. one service daemon refused to start) is a pain. also a pain when you need to use multiple radios (i.e. make sure service is not stopped if another radio is present, etc.). its just easier, imo, to have service daemons to listen on wildcard addresses and be done with it. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 18:01:04 2009 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 ED7CD106566C for ; Thu, 5 Feb 2009 18:01:04 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 95DF48FC18 for ; Thu, 5 Feb 2009 18:01:04 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so169714ywe.13 for ; Thu, 05 Feb 2009 10:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XABnpb0LLM4YNxL/814SuPgad/7wOTyUZuWEtlT9dlo=; b=Cq0m5LXY9/lasZwY48vfniAntmc0WKU+zFJkYLSy1OMoCOY0gPRDlhmSxIeXsUCCul f9tenFD/s13TrcbHN0SYSi/Q21eP6OGUcP/Az8uts2UAtDRFZPww3+qu90KDNIQcm2wU 8RZRC9AHjrBQDuz/nP4/WcMl97rmEL//JTnjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=veFlbFKvjQV0AJALt1Inx/3JXDx12tlektKntP6gVrmM3oPHSbJuc4XtdHQcqwnjCt HyXr9/qqzaXCoqOeN8/k4A2Gxg/1aRfgm1tsxoFExZ1A7BE/K75eS5q93rlzzX4TFDFk taeZ4w7eOTwksqD4/1Y6jViLj7FaYu3LEQA+o= MIME-Version: 1.0 Received: by 10.150.137.14 with SMTP id k14mr270075ybd.173.1233856863967; Thu, 05 Feb 2009 10:01:03 -0800 (PST) In-Reply-To: <1233845167.798942.24919.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> <1233845167.798942.24919.nullmailer@galant.ukfsn.org> Date: Thu, 5 Feb 2009 10:01:03 -0800 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: libhci 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, 05 Feb 2009 18:01:05 -0000 On Thu, Feb 5, 2009 at 6:46 AM, Iain Hibbert wrote: > On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > >> int hci_inquiry(...) >> >> and all the way down to the end of the file :) basically map dev_id to >> unit numbers, i.e. dev_id 0 is "ubt0" node, etc. > > Well, I really dislike that dev_id method to start with. But anyway, I > think they are working on a new API that is somewhat higher level and more > related to the dbus access. of course they are :) its linux :) they always working on something new and improved :) anyway, what would you suggest to use instead of dev_id? device name (i.e. ubt0)? anything else? cant use bd_addr because (in freebsd at least) device has to be "initialized" before bd_addr is known. > Also, I think that looking at that code, it was written in the beginning > and is full of 'good ideas' that somebody might want to use, but in > reality much of it has no need to be in a shared library. > > hci_inquiry() is perhaps the only function that really needs to have a > generic cross platform API and it would be nice if it was oriented towards > application level rather than tied to a lower layer implementation. I do > not know what kind of API the Microsoft (Widcom?) or Apple stacks expose > to applications for this, but I suspect they would be a better place to > start. i will take a look at ms api. but surely we have ability to send and receive hci commands/events and enumerate all radios in the system in addition to inquiry, dont you think? thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 19:31:49 2009 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 5E42210656D8 for ; Thu, 5 Feb 2009 19:31:49 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id B006E8FC1D for ; Thu, 5 Feb 2009 19:31:48 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233692054; Thu, 05 Feb 2009 21:31:47 +0200 Message-ID: <498B3EA9.1030403@mavhome.dp.ua> Date: Thu, 05 Feb 2009 21:31:53 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 05 Feb 2009 19:31:50 -0000 Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 10:37 PM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>> [...] >>> >>>>>>> so, imo, there is nothing really prevents us from using multiple local >>>>>>> radios. also mac address on tap interface is really does not matter, >>>>>>> because its get stripped anyway. that is unless tap interface checks >>>>>>> dst mac address and make sure it matches (like freebsd does) before >>>>>>> passing packet up the stack. if any case, setting promisc. flag on >>>>>>> interface will fix it. the only mess here is that arp responses for >>>>>>> local tap interface will contain mac address of tap interface and not >>>>>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>>>>> its properly encapsulated into bnep, imo, it should work. so even if >>>>>>> both endpoints have a direct rf link, it will look like they are not. >>>>>> I still think we should not do such hacks. As I understand there is OK >>>>>> to >>>>>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>>>>> MAC >>>>>> addresses does not match to BDADDRs, packets should just be transmitter >>>>>> with >>>>>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>>>>> to >>>>>> BDADDR just as much as possible to maximally benefit from header >>>>>> compression. But if we have single TAP interface on server, which >>>>>> handles >>>>>> several links via different adapters, I understand it should be fine to >>>>>> just >>>>>> choose one of BDADDRs as MAC address to be completely honest to >>>>>> everybody. >>>>>> If there is only one adapter, then all headers will be compressed, if >>>>>> there >>>>>> is several - only part of them. >>>>>> >>>>>> Am I right? >>>>> well, yes and no. somehow you need to map multiple local bd_addr to >>>>> either one bd_addr or completely different mac address on tap >>>>> interface. somehow i think that having completely different mac >>>>> address on tap interface and map all the local bd_addr's to it makes >>>>> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >>>>> i like the ability to bind to wildcard address, it allows us to run >>>>> bluetooth servers even if there are no bluetooth radios connected to >>>>> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >>>>> when i need, i simply plug my usb bluetooth dongle it - presto - it >>>>> all works. magic! :) if you bind to a particular radio, then you tied >>>>> to it. cant do anything before radio is present and cant do anything >>>>> after radio is gone. >>>> If there is no any radio present yet, you can just choose any random MAC >>>> address for TAP and transfer it via BNEP later. You will loose 6 bytes >>>> per >>>> packet due to addresses mismatch, but it should work. By doing >>>> unconditional >>> tap is already getting "randomly" selected mac address by default. >>> >>>> translation of TAP MAC address into BDADDR, you will make impossible >>>> bridging between Bluetooth and local network, which is interesting, as >>>> can >>>> be used, for example, as cheap and low power WiFi alternative. >>> huh? please explain why. i think if you want to put your nap >>> (wireless) clients onto the same wired lan you might have on your nap >>> server you will have to do bridging no matter what. >> I just mean that bridging should be clean, you should pass LAN MAC addresses >> to Bluetooth directly without mapping to BDADDR and without compression. > > i'm very confused now :) of course wired lan addresses will be passed > to wireless clients as is, and, without any header compression. i'm > talking about mapping local (to nap server) radio(s) bd_addr to local > (to nap server) tap interface mac address. the nap server should never > give any reason, to any directly attached wireless client, to use > radio's bd_addr instead of tap interface mac address. in other words, > the nap server should never use "no src" nor "no src, no dst" bnep > headers. all locally (on the nap server) generated packets should > always have src address set in bnep header and this src address should > be the mac address set on the tap interface. on receiving side, the > nap server should check "dst" address against the tap interface mac > address and if they match, put packet into the tap device. also, > assuming things are working correctly, the nap server should never get > packets without "dst" set in bnep header. > > so, other than wasting 6 bytes, i do not see any downside to this > approach. did i miss anything here? Sorry, looks like I have misunderstood your: "map multiple local bd_addr to either one bd_addr". I have read it as you are going to interpret fake TAP address as equal to BDADDR and silently compress it. I was against that. I would like to say about that we can: 1) or, as you have just said, set completely fake TAP address and never compress it, as it is never equal, 2) or, as I have told recently, get real BDADDR of any adapter present in system (preferably related) and use it's address for TAP, then for traffic passing via that adapter compression could be used, saving 6 bytes. For usual systems with one adapter it will make that all locally originated/terminated traffic will have compressed src/dst address. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 21:05:23 2009 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 B88BC106567B for ; Thu, 5 Feb 2009 21:05:23 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 633AA8FC1D for ; Thu, 5 Feb 2009 21:05:23 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so222773ywe.13 for ; Thu, 05 Feb 2009 13:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SelmgWOMkzDGnDsNPi2kN7pEo2AvmDNLS78mxkv0x9Q=; b=OLZSjtFgVQ1wJq8jk7AI2RqTZotSroN3//Mq1teqa8bcdRCQrPPeL+WpZXBikoSF2s dvC7mWMFqekOl/R3che0n4Pw4K2dPj9OXDCPC/4im7kQJMbfKaLFlHIc+8KiJ8ay5uDJ 7rVCpo0tlgeX3p5b2P4AvoF6cDfPkN5p42VbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=US7SW3uFoCffKWQvY3QLveglfRxQWNvlh/ms/5l/9Tcq7RnKRC6+A4B0hxgmfgTspg FledCQba8tmqLcsylXCwruHXs4hZhHx6CqftXqkS7W0cd0pLbtBQxnZMThQzfG84Do3N OSR/YQ+NEx7ZLJrMlhVoXjP35UwlW6pVB3T5A= MIME-Version: 1.0 Received: by 10.151.15.13 with SMTP id s13mr50698ybi.24.1233867922449; Thu, 05 Feb 2009 13:05:22 -0800 (PST) In-Reply-To: <498B3EA9.1030403@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> <498B3EA9.1030403@mavhome.dp.ua> Date: Thu, 5 Feb 2009 13:05:20 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 05 Feb 2009 21:05:24 -0000 [...] >>>>> If there is no any radio present yet, you can just choose any random >>>>> MAC >>>>> address for TAP and transfer it via BNEP later. You will loose 6 bytes >>>>> per >>>>> packet due to addresses mismatch, but it should work. By doing >>>>> unconditional >>>> >>>> tap is already getting "randomly" selected mac address by default. >>>> >>>>> translation of TAP MAC address into BDADDR, you will make impossible >>>>> bridging between Bluetooth and local network, which is interesting, as >>>>> can >>>>> be used, for example, as cheap and low power WiFi alternative. >>>> >>>> huh? please explain why. i think if you want to put your nap >>>> (wireless) clients onto the same wired lan you might have on your nap >>>> server you will have to do bridging no matter what. >>> >>> I just mean that bridging should be clean, you should pass LAN MAC >>> addresses >>> to Bluetooth directly without mapping to BDADDR and without compression. >> >> i'm very confused now :) of course wired lan addresses will be passed >> to wireless clients as is, and, without any header compression. i'm >> talking about mapping local (to nap server) radio(s) bd_addr to local >> (to nap server) tap interface mac address. the nap server should never >> give any reason, to any directly attached wireless client, to use >> radio's bd_addr instead of tap interface mac address. in other words, >> the nap server should never use "no src" nor "no src, no dst" bnep >> headers. all locally (on the nap server) generated packets should >> always have src address set in bnep header and this src address should >> be the mac address set on the tap interface. on receiving side, the >> nap server should check "dst" address against the tap interface mac >> address and if they match, put packet into the tap device. also, >> assuming things are working correctly, the nap server should never get >> packets without "dst" set in bnep header. >> >> so, other than wasting 6 bytes, i do not see any downside to this >> approach. did i miss anything here? > > Sorry, looks like I have misunderstood your: "map multiple local bd_addr to > either one bd_addr". I have read it as you are going to interpret fake TAP > address as equal to BDADDR and silently compress it. I was against that. > > I would like to say about that we can: > 1) or, as you have just said, set completely fake TAP address and never > compress it, as it is never equal, > 2) or, as I have told recently, get real BDADDR of any adapter present in > system (preferably related) and use it's address for TAP, then for traffic > passing via that adapter compression could be used, saving 6 bytes. For > usual systems with one adapter it will make that all locally > originated/terminated traffic will have compressed src/dst address. its not even interesting anymore :) imo, there is very little reason to set tap interface to any radio's bd_addr. it makes perfect sense (to me) to keep whatever mac address assigned to tap by default because that is the interface on which traffic is flowing. radio is just a transport. it is still possible to compress dst address in bnep header, so, like i said, the overhead is only 6 bytes. that is 6/1500 = 0.4% (!), and, i bet you won't even be able to measure it. oh, and keep in mind that bnep _replaces_ original ethernet header, so even if you don't do _any_ compression at all, you are not doing worse. this is a very reasonable price to pay to support multiple radios and listening on wildcard address without adding extra complexity to the code. plus, like you said, it only can compress src on only one radio link anyway, so the more radios you have, the less "win" you will get. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 21:18:25 2009 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 AD726106564A for ; Thu, 5 Feb 2009 21:18:25 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2836D8FC16 for ; Thu, 5 Feb 2009 21:18:24 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233698669; Thu, 05 Feb 2009 23:18:23 +0200 Message-ID: <498B57A5.6080406@mavhome.dp.ua> Date: Thu, 05 Feb 2009 23:18:29 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> <498B3EA9.1030403@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd 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, 05 Feb 2009 21:18:25 -0000 Maksim Yevmenkin wrote: >> I would like to say about that we can: >> 1) or, as you have just said, set completely fake TAP address and never >> compress it, as it is never equal, >> 2) or, as I have told recently, get real BDADDR of any adapter present in >> system (preferably related) and use it's address for TAP, then for traffic >> passing via that adapter compression could be used, saving 6 bytes. For >> usual systems with one adapter it will make that all locally >> originated/terminated traffic will have compressed src/dst address. > > its not even interesting anymore :) imo, there is very little reason > to set tap interface to any radio's bd_addr. it makes perfect sense > (to me) to keep whatever mac address assigned to tap by default > because that is the interface on which traffic is flowing. radio is > just a transport. > > it is still possible to compress dst address in bnep header, so, like > i said, the overhead is only 6 bytes. that is 6/1500 = 0.4% (!), and, > i bet you won't even be able to measure it. oh, and keep in mind that > bnep _replaces_ original ethernet header, so even if you don't do > _any_ compression at all, you are not doing worse. > > this is a very reasonable price to pay to support multiple radios and > listening on wildcard address without adding extra complexity to the > code. plus, like you said, it only can compress src on only one radio > link anyway, so the more radios you have, the less "win" you will get. Ok, as you wish, simplicity is good, but if it sometimes would be not difficult to implement 2, it still would be not bad. The only thing should be tested is WM compatibility. Iain was written that there is some problems he noticed if addresses differs. -- Alexander Motin From owner-freebsd-bluetooth@FreeBSD.ORG Fri Feb 6 11:32:44 2009 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 20A6710656D5 for ; Fri, 6 Feb 2009 11:32:44 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id D11BA8FC1B for ; Fri, 6 Feb 2009 11:32:43 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LVOwp-0004WT-9f; Fri, 06 Feb 2009 11:32:39 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17261-06; Fri, 6 Feb 2009 11:32:38 +0000 (GMT) Received: from [10.35.25.189] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LVOwW-0004VV-8C; Fri, 06 Feb 2009 11:32:38 +0000 Received: (nullmailer pid 24503 invoked by uid 1000); Fri, 06 Feb 2009 11:31:20 -0000 Date: Fri, 6 Feb 2009 11:31:20 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> <1233845167.798942.24919.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1233919880.530235.10843.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: libhci 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: Fri, 06 Feb 2009 11:32:44 -0000 On Thu, 5 Feb 2009, Maksim Yevmenkin wrote: > anyway, what would you suggest to use instead of dev_id? device name > (i.e. ubt0)? anything else? cant use bd_addr because (in freebsd at > least) device has to be "initialized" before bd_addr is known. for sure, a generic API would need to use the device name. Internally it can translate to whatever the local hardware control API uses. > i will take a look at ms api. but surely we have ability to send and > receive hci commands/events and enumerate all radios in the system in > addition to inquiry, dont you think? enumerating the radios is useful, yes, but having a function to set the afh_map or some other setting? I think that this is only required by the administrator program (hccontrol in your case) so why does it need to be in a shared library? In a way, its similar for the string functions. What program needs to be able to print the features list? Only a shell based admin tool in reality, even a graphical program might want to provide such a feature list in a different format anyway.. iain