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