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