Date: Mon, 20 Dec 2004 11:40:11 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: vova@fbsd.ru Cc: bluetooth@freebsd.org Subject: Re: Bluetooth mouse Message-ID: <41C72A9B.6090405@savvis.net> In-Reply-To: <1103527349.1024.18.camel@localhost> References: <1100552998.1098.5.camel@localhost> <419B8353.7040908@savvis.net> <opshmg45c1lo1qsj@mail.xs4all.nl> <419B9EF8.2090401@savvis.net> <1103269957.974.7.camel@localhost> <41C32471.2050805@savvis.net> <866530fusa.fsf@kamino.rfc1149.org> <41C35B92.7080908@savvis.net> <1103489813.1721.14.camel@localhost> <41C63A62.20304@savvis.net> <1103527349.1024.18.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Vladimir,
>>> # cat /var/db/bthidd.hids 00:07:61:17:9b:27
>>
>> hmmm... you did not hand-edit /var/db/bthidd.hids, did you? this
>> file is not supposed to be edited by user. this file contains
>> "hints" for bthidd(8), that is bluetooth hid devices "known" to
>> bthidd(8).
>
> Yes, I did. I've edited it while tried to make mouse works.
you should not edit this file by hand.
>>> When I start bthidd it waits for mouse connection forever,
>>> clicking on mouse connect button does not seems to have any
>>> effect, moreover hcidump does not show any traffic.
>>
>> again if you hand-edited /var/db/bthidd.hids, then this is the
>> correct behavior. the typical behavior of bluetooth hid devices is:
>> the very first time bluetooth hid device needs to be contacted by
>> the host. this is because in its default state bluetooth hid device
>> does not know anything about host, i.e. its bd_addr etc. in its
>> default state the hid device will answer inquiry, etc. the host
>> finds new hid device and initiates bluetooth hid session (opens
>> interrupt and control channels). after the hid device was contacted
>> by the host for the very first time, the hid device will "remember"
>> host bd_addr. after that bluetooth hid device will reject all
>> connection attempts from the different hosts and may even stop
>> responding to inquires.
>
> I see.
good.
>> 0) run hcidump -w mouse.dump as root
>>
>> 1) make sure bthidd(8) is NOT running
>>
>> 2) reset the mouse (press reset button or disconnect batteries for
>> a few seconds)
>>
>> 3) use bthidcontrol(8) to query the mouse
>>
>> 4) put output of the bthidcontrol(8) in the
>> /etc/bluetooth/bthidd.conf
>>
>> 5) make sure mouse bd_addr IS *NOT* in the /var/db/bthidd.hids
>>
>> 6) (OPTIONAL) *if* your mouse requests authentication then edit
>> /etc/bluetooth/hcsecd.conf file and add pin code or link key. the
>> pin code can be obtained from the mouse documentation. after that
>> run hcsecd(8)
>
> looks like it does not require key or pin, also winXP connects only
> without pin.
how can you tell? the pin code may be hardwired somewhere in the windows
registry. did windows software prompt you for anything during install?
can you check all the documentation that came with the mouse to see if
there is a pin code?
Arne: could you please tell us what did you do to make your mouse work?
>> 7) start bthidd(8)
>>
>> if you did everything right the mouse should work.
>
> Still no luck, but this time there is attempt to connect from host to
> mouse on bthidd start:
>
> # bthidd -d bthidd[1398]: Opening outbound session for
> 00:07:61:17:9b:27 (new_device=1, reconnect_initiate=1) bthidd[1398]:
> Could not connect to 00:07:61:17:9b:27. Socket is not connected (57)
that the way it should work.
> There hcidump output while bthidd connection attempt # hcidump -r
> mouse.dump HCIDump - HCI packet analyzer ver 1.5
[...]
1103525841.696334 < ACL data: handle 0x002a flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0060
here host is trying to open hid-control channel (psm 17 (0x11))
1103525841.738294 > ACL data: handle 0x002a flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x005c scid 0x0060 result 1 status 2
1103525841.772308 > ACL data: handle 0x002a flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0060 result 2 status 0
and these are mouse responses. the first response returns with result
code 1 (Connection Pending) and status code 2 (Authorization Pending).
the second response is with result code 2 (PSM Not Supported) and status
code 0 (No Information).
note timestamps - responses are only 34 msec apart - not much time. so
it looks like the mouse does not like the host.
are you using different bluetooth adapters on your freebsd and winxp
boxes? if so, can you try and use winxp adapter on your freebsd box?
also did you check the manual to find out what is the correct reset
procedure for the mouse?
> also, after hardware reset by batteries, /var/db/bthidd.hids get
> address of mouse, but do not write anything new to output and mouse
> still does not work.
ok
> bthidd[1610]: Opening outbound session for 00:07:61:17:9b:27
> (new_device=1, reconnect_initiate=1) bthidd[1610]: Could not connect
> to 00:07:61:17:9b:27. Socket is not connected (57)
>
> hcidump while this is:
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x006d
again host is trying to open hid-control channel
> ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0042 scid 0x006d result 1 status 2
> ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0042 scid 0x006d result 0 status 0
whoa! this time it has opened hid-control channel. lets see what happens
next...
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0042 flags 0x0000 clen 0
> ACL data: handle 0x0029 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x006d flags 0x0000 result 0 clen 0
here host configures its side of the l2cap channel (hid control) and
mouse accepts it.
> ACL data: handle 0x0029 flags 0x01 dlen 13
L2CAP(s): Config req: dcid 0x006d flags 0x0000 clen 28
MTU 48 Unknown (type 03, len 22)
< ACL data: handle 0x0029 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0042 flags 0x0000 result 0 clen 0
here mouse configures its side of the l2cap channel (hid control), sets
mtu and qos. (ignore Unknown - hcidump does not know how to parse qos
option). host accepts it.
so far everything looks fine to me. after this point hid control channel
should be opened and configured. the next step is to open hid
interrupt channel.
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 25 scid 0x006e
> ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0000 scid 0x006e result 2 status 0
ok, this does not make any sense. psm 25 ?! why the hell it tries to
connect to psm 25? of course mouse tells host to get lost, because it
does not want to talk on psm 25.
wait, i know why. i just checked your older email and find out that you have
"interrupt_psm 0x19;"
line in your /etc/bluetooth/bthidd.conf file (mouse section). could you
please try to change it to
"interrupt_psm 0x13;"
then do the following:
0) run 'hcidump -w mouse.dump' as root
1) remove mouse bd_addr from /var/db/bthidd.hids file
2) disconnect and reconnect batteries on your mouse
3) press 'connect' button on your mouse
4) restart bthidd(8)
> It happens when I disconnect/connect batteries and then press connect
> button.
>
> Even after that mouse does not moved. if I restart bthidd - it does
> not connects and mouse does not send any traffic.
it will not move - you do not have hid session, that is you need to open
both hid control and hid interrupt channels.
if the above works then there is a problem with
1) bthidcontrol(8) - because it has incorrectly parsed sdp response and
showed wrong psm for the hid interrupt channel. that is what you put
into the /etc/bluetooth/bthidd.conf file (unless of course you
hand-edited it as well)
or
2) mouse itself. it advertises wrong psm for the hid interrupt channel.
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C72A9B.6090405>