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