I tried to switch to Windows and back. Although the mouse still stays
still upon reboot back to Ubuntu, I noticed one thing: the bluetooth
preferences dialog will show a "computer" icon indicating connection
established when I switched the visibility setting AND move the mouse.
However, the icon will disappear in a second or two and the mouse has
never moved.
I repeat this process and used hcidump to sniff the bluetooth
communication: I saw some interesting output as following:
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0040
< ACL data: handle 7 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 7 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 7 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 7 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 7 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
< ACL data: handle 7 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 48
< ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 7 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x0041
< ACL data: handle 7 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 7 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 48
< ACL data: handle 7 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 48
< ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 7 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 7 flags 0x02 dlen 7
L2CAP(d): cid 0x0041 len 3 [psm 19]
HIDP: Data: Output report
< ACL data: handle 7 flags 0x02 dlen 11
L2CAP(d): cid 0x0041 len 7 [psm 19]
HIDP: Data: Output report
< ACL data: handle 7 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 19]
HIDP: Data: Output report
> ACL data: handle 7 flags 0x02 dlen 11
L2CAP(d): cid 0x0041 len 7 [psm 19]
HIDP: Data: Input report
> ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0041
< ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0041
> ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 7 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Disconn Complete (0x05) plen 4
As can be seen at the beginning, the incoming connecting request is
indeed made by the mouse and a normal handshake procedure is then going
normally until at the very end, the mouse weirdly made a disconnecting
request which results the termination of the connection.
I compared this with 2 other processes: a) Using "hidd --search" to add
the mouse (which can correctly establish the connection) and b) Using
bluetooth applet to add the mouse as a new device (after deleting the
existed one)
In case a) the hcidump output is almost the same as above, except the in
and out directions are switched because obviously when pairing a mouse,
it is the computer side which starts the request. And there is no
disconnecting request at the end.
In case b) the communication looks like this:
< ACL data: handle 6 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 6 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 4 status 0
Connection refused - no resources available
< ACL data: handle 6 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 6 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
< HCI Command: Disconnect (0x01|0x0006) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Disconn Complete (0x05) plen 4
The initial request is a bit *different* as it uses "psm 17" together
with "scid 0x0041", previous ones are always "psm 17" with "scid 0x0040"
and "psm 19" with "scid 0x0041". I don't know exactly what these "psm"
and "scid" means but after all this type of connecting request is
refused by the mouse and eventually the computer issued a disconnecting
request to end the procedure. This might be why the mouse keeps being in
a pairing mode and never returns but it feels a bit deceiving that the
dialog tells you the pairing is finished despite the fact it is refused.
I hope the above information can give some hints to anyone who knows the
inside story of the bluez system and can eventually help to solve this
issue.
--
[Jaunty] Cannot connect to a bluetooth mouse
https://bugs.launchpad.net/bugs/343727
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
