pan profile support in freebsd

[Maksim Yevmenkin]

[...]

>> 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