Maksim Yevmenkin wrote:
On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin <[email protected]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[email protected]"
