atom feed39 messages in org.freebsd.freebsd-bluetoothRe: pan profile support in freebsd
FromSent OnAttachments
Alexander MotinFeb 3, 2009 4:09 pm 
Maksim YevmenkinFeb 3, 2009 4:21 pm 
Alexander MotinFeb 3, 2009 5:12 pm 
Maksim YevmenkinFeb 3, 2009 5:31 pm 
Alexander MotinFeb 3, 2009 6:06 pm 
Iain HibbertFeb 4, 2009 6:41 am 
Iain HibbertFeb 4, 2009 6:57 am 
Iain HibbertFeb 4, 2009 7:10 am 
Maksim YevmenkinFeb 4, 2009 9:46 am 
Maksim YevmenkinFeb 4, 2009 9:59 am 
Alexander MotinFeb 4, 2009 10:39 am 
Alexander MotinFeb 4, 2009 11:07 am 
Alexander MotinFeb 4, 2009 11:27 am 
Iain HibbertFeb 4, 2009 11:31 am 
Alexander MotinFeb 4, 2009 11:53 am 
Maksim YevmenkinFeb 4, 2009 12:01 pm 
Alexander MotinFeb 4, 2009 12:13 pm 
Iain HibbertFeb 4, 2009 12:26 pm 
Maksim YevmenkinFeb 4, 2009 1:16 pm 
Alexander MotinFeb 4, 2009 1:50 pm 
Maksim YevmenkinFeb 4, 2009 2:27 pm 
Alexander MotinFeb 4, 2009 2:40 pm 
Maksim YevmenkinFeb 4, 2009 3:00 pm 
Alexander MotinFeb 4, 2009 10:36 pm 
Federico LorenziFeb 5, 2009 12:05 am 
Iain HibbertFeb 5, 2009 6:28 am 
Iain HibbertFeb 5, 2009 6:45 am 
Maksim YevmenkinFeb 5, 2009 9:50 am 
Maksim YevmenkinFeb 5, 2009 9:55 am 
Maksim YevmenkinFeb 5, 2009 10:00 am 
Alexander MotinFeb 5, 2009 11:31 am 
Maksim YevmenkinFeb 5, 2009 1:04 pm 
Alexander MotinFeb 5, 2009 1:17 pm 
Iain HibbertFeb 6, 2009 3:30 am 
Maksim YevmenkinFeb 13, 2009 5:17 pm.txt
Iain HibbertFeb 14, 2009 1:52 am 
Maksim YevmenkinMar 5, 2009 11:03 am.txt
Iain HibbertMar 5, 2009 12:14 pm 
Maksim YevmenkinMar 5, 2009 2:59 pm.txt
Subject:Re: pan profile support in freebsd
From:Alexander Motin (ma@mavhome.dp.ua)
Date:Feb 3, 2009 6:06:37 pm
List:org.freebsd.freebsd-bluetooth

Maksim Yevmenkin wrote:

On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin <ma@mavhome.dp.ua> 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)