Date: Wed, 04 Feb 2009 04:07:19 +0200 From: Alexander Motin <mav@mavhome.dp.ua> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: pan profile support in freebsd Message-ID: <4988F857.5080407@mavhome.dp.ua> In-Reply-To: <bb4a86c70902031731q83bf261s49e5812a3c208f81@mail.gmail.com> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <bb4a86c70902031622hdc5231g1c9ce33f17842a1e@mail.gmail.com> <4988EBAC.3080202@mavhome.dp.ua> <bb4a86c70902031731q83bf261s49e5812a3c208f81@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote:
> On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin <mav@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)
--
Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4988F857.5080407>