pan profile support in freebsd

[Maksim Yevmenkin]

On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin <mav at 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 :)

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