Hi!
Running 2.6.8 mh2, bluz-utils 2.10 on Debian Sarge. Marcel, please
excuse me for mailing you directly as wellas the list, as I want to send
you a binary hcidump output so you can get maximum debug info.
I am having problems with the keyboard not reconnecting on reboot when
hciattach switches the internal dongle from USB HID emulation to HCI.
The Lower level layer is definitely connected, but the keyboard events
are not generating keyboard input at all. I have to switch the keyboard
off, and then switch it back on, and it renegotiates, and it all starts
working.
This test is not using security mode 3 yet, though I will be doing this
to prevent people sniffing passwords.... but the same problem happens
then.
When I boot from OS X back into Linux, the problem does not occur.
I have attached the hcidump binary session data so that you can all look
at it. If it does not turn up on the mailing list, please email me to
send it to you. My hcid.conf is included down the bottom.
Here is the screen session I did when playing with keyboard, while using
an ordinary USB keyboard:
root@sharon:/home/grantma#
# hcitool con
Connections:
> ACL 00:0A:95:3B:0B:49 handle 46 state 1 lm MASTER
root@sharon:/home/grantma#
# hcitool dc 00:0A:95:3B:0B:49
Disconnect failed: Connection timed out
root@sharon:/home/grantma#
# hcitool dc 00:0A:95:3B:0B:49
Not connected.
root@sharon:/home/grantma#
# hcitool con
Connections:
root@sharon:/home/grantma#
# hcitool con
Connections:
> ACL 00:0A:95:3B:0B:49 handle 47 state 1 lm MASTER
root@sharon:/home/grantma#
# hcitool con
Connections:
> ACL 00:0A:95:3B:0B:49 handle 47 state 1 lm MASTER
root@sharon:/home/grantma#
#
This is the output of hcidump 1.12 (hcidump -X) when I start trying to
use the keyboard:
HCIDump - HCI packet analyzer ver 1.12
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 00 00 00 00 00 00 ..........
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 00 00 00 00 00 00 ..........
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 00 00 00 00 00 00 ..........
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 00 00 00 00 00 00 ..........
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 00 00 00 00 00 00 ..........
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> ACL data: handle 0x002e flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 00 00 00 00 00 00 ..........
< HCI Command: Disconnect (0x01|0x0006) plen 3
0000: 2e 00 13 ...
> HCI Event: Command Status (0x0f) plen 4
0000: 00 01 06 04 ....
> HCI Event: Disconn Complete (0x05) plen 4
0000: 00 2e 00 16 ....
> HCI Event: Connect Request (0x04) plen 10
0000: 49 0b 3b 95 0a 00 40 25 00 01 I.;...@%..
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
0000: 49 0b 3b 95 0a 00 00 I.;....
> HCI Event: Command Status (0x0f) plen 4
0000: 00 01 09 04 ....
> HCI Event: Role Change (0x12) plen 8
0000: 00 49 0b 3b 95 0a 00 00 .I.;....
> HCI Event: Connect Complete (0x03) plen 11
0000: 00 2f 00 49 0b 3b 95 0a 00 01 00 ./.I.;.....
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
0000: 2f 00 0f 00 /...
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
0000: 49 0b 3b 95 0a 00 01 I.;....
> ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x004d
< ACL data: handle 0x002f flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x004d result 0 status 0
> HCI Event: Command Complete (0x0e) plen 6
0000: 01 0d 08 00 2f 00 ..../.
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
0000: 2f 00 18 cc /...
> HCI Event: Command Status (0x0f) plen 4
0000: 00 01 0f 04 ....
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
0000: 00 2f 00 18 00 ./...
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0
< ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x004d flags 0x0000 result 0 clen 0
< ACL data: handle 0x002f flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x004d flags 0x0000 clen 4
MTU 48
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 1
L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 4
MTU 48
> ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x004e
< ACL data: handle 0x002f flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x004e result 0 status 0
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 0
< ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x004e flags 0x0000 result 0 clen 0
< ACL data: handle 0x002f flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x004e flags 0x0000 clen 4
MTU 48
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 1
L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 4
MTU 48
< ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0042
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x004f scid 0x0042 result 0 status 0
< ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x004f flags 0x0000 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> HCI Event: Mode Change (0x14) plen 6
0000: 00 2f 00 02 14 00 ./....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0042 flags 0x0000 result 0 clen 0
> ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0042 flags 0x0000 clen 0
< ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x004f flags 0x0000 result 0 clen 0
< ACL data: handle 0x002f flags 0x02 dlen 24
L2CAP(d): cid 0x004f len 20 [psm 1]
SDP SSA Req: tid 0x0 len 0xf
pat uuid-16 0x1200 (PNPInfo)
max 0xffff
aid(s) 0x0000 - 0xffff
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 15
L2CAP(d): cid 0x0042 len 96 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x5b
cnt 0x58
srv rec #0
aid 0x0000 (SrvRecHndl)
uint 0x10001
aid 0x0001 (SrvClassIDList)
< uuid-16 0x1200 (PNPInfo) >
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) uint 0x1 > <
uuid-16 0x0001 (SDP) > >
aid 0x0009 (BTProfileDescList)
< < uuid-16 0x1200 (PNPInfo) uint 0x100 > >
aid 0x0200 (VersionNumList)
uint 0x100
aid 0x0201 (SrvDBState)
uint 0x5ac
aid 0x0202 (unknown)
uint 0x208
aid 0x0203 (unknown)
uint 0x110
aid 0x0204 (unknown)
bool 0x1
aid 0x0205 (unknown)
uint 0x2
cont 00
< ACL data: handle 0x002f flags 0x02 dlen 24
L2CAP(d): cid 0x004f len 20 [psm 1]
SDP SSA Req: tid 0x1 len 0xf
pat uuid-16 0x1124 (HID)
max 0xffff
aid(s) 0x0000 - 0xffff
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> HCI Event: Mode Change (0x14) plen 6
0000: 00 2f 00 00 00 00 ./....
> ACL data: handle 0x002f flags 0x02 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 13
L2CAP(d): cid 0x0042 len 128 [psm 1]
SDP SSA Rsp: tid 0x1 len 0x7b
cnt 0x76
srv rec #0
aid 0x0000 (SrvRecHndl)
uint 0x10000
aid 0x0001 (SrvClassIDList)
< uuid-16 0x1124 (HID) >
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) uint 0x11 > <
uuid-16 0x0011 (HIDP) > >
aid 0x0005 (BrwGrpList)
< uuid-16 0x1002 (PubBrwsGrp) >
aid 0x0006 (LangBaseAttrIDList)
< uint 0x656e uint 0x6a uint 0x100 >
aid 0x0009 (BTProfileDescList)
< < uuid-16 0x1124 (HID) uint 0x100 > >
aid 0x000d (IconURL)
< < < uuid-16 0x0100 (L2CAP) uint 0x13 > < uuid-16 0x0011
(HIDP) > > >
aid 0x0100 (SrvName)
str "Apple Wireless Key"
cont
< ACL data: handle 0x002f flags 0x02 dlen 26
L2CAP(d): cid 0x004f len 22 [psm 1]
SDP SSA Req: tid 0x2 len 0x11
pat uuid-16 0x1124 (HID)
max 0xffff
aid(s) 0x0000 - 0xffff
cont 02 00 76
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 13
L2CAP(d): cid 0x0042 len 128 [psm 1]
SDP SSA Rsp: tid 0x2 len 0x7b
cnt 0x76
ERROR: Unexpected syntax
0000: 6f 61 72 64 09 01 01 25 17 41 70 70 6c 65 20 57
oard...%.Apple W
0010: 69 72 65 6c 65 73 73 20 4b 65 79 62 6f 61 72 64
ireless Keyboard
0020: 09 01 02 25 14 41 70 70 6c 65 20 43 6f 6d 70 75
...%.Apple Compu
0030: 74 65 72 2c 20 49 6e 63 2e 09 02 00 09 01 10 09 ter,
Inc........
0040: 02 01 09 01 11 09 02 02 08 40 09 02 03 08 21 09
.........@....!.
0050: 02 04 28 01 09 02 05 28 01 09 02 06 35 69 35 67
..(....(....5i5g
0060: 08 22 25 63 05 01 09 06 a1 01 85 01 05 07 19 e0
."%c............
0070: 29 e7 15 00 25 02 00 ec
)...%...
cont 6F 61 72 64 09 01 01 25 17 41 70 70 6C 65 20 57 69 72 65
6C 65 73 73 20 4B 65 79 62 6F 61 72 64 09 01 02 25 14 41 70 70 6C 65 20
43 6F 6D 70 75 74 65 72 2C 20 49 6E 63 2E 09 02 00 09 01 10 09 02 01 09
01 11 09 02 02 08 40 09 02 03 08 21 09 02 04 28 01 09 02 05 28 01 09 02
06 35 69 35 67 08 22 25 63 05 01 09 06 A1 01 85 01 05 07 19 E0 29 E7 15
00 25 02 00 EC
< ACL data: handle 0x002f flags 0x02 dlen 26
L2CAP(d): cid 0x004f len 22 [psm 1]
SDP SSA Req: tid 0x3 len 0x11
pat uuid-16 0x1124 (HID)
max 0xffff
aid(s) 0x0000 - 0xffff
cont 02 00 EC
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 13
L2CAP(d): cid 0x0042 len 128 [psm 1]
SDP SSA Rsp: tid 0x3 len 0x7b
cnt 0x76
ERROR: Unexpected syntax
0000: 75 01 95 08 81 02 75 08 95 01 81 01 75 01 95 05
u.....u.....u...
0010: 05 08 19 01 29 05 91 02 75 03 95 01 91 01 75 08
....)...u.....u.
0020: 95 06 15 00 26 ff 00 05 07 19 00 2a ff 00 81 00
....&......*....
0030: 75 01 95 01 15 00 25 01 05 0c 09 b8 81 06 09 e2
u.....%.........
0040: 81 06 09 e9 81 02 09 ea 81 02 75 01 95 04 81 01
..........u.....
0050: c0 09 02 07 35 08 35 06 09 04 09 09 01 00 09 02
....5.5.........
0060: 08 28 00 09 02 0a 28 01 09 02 0b 09 01 00 09 02
.(....(.........
0070: 0c 09 1f 40 09 02 01 62
[email protected]
cont 75 01 95 08 81 02 75 08 95 01 81 01 75 01 95 05 05 08 19
01 29 05 91 02 75 03 95 01 91 01 75 08 95 06 15 00 26 FF 00 05 07 19 00
2A FF 00 81 00 75 01 95 01 15 00 25 01 05 0C 09 B8 81 06 09 E2 81 06 09
E9 81 02 09 EA 81 02 75 01 95 04 81 01 C0 09 02 07 35 08 35 06 09 04 09
09 01 00 09 02 08 28 00 09 02 0A 28 01 09 02 0B 09 01 00 09 02 0C 09 1F
40 09 02 01 62
< ACL data: handle 0x002f flags 0x02 dlen 26
L2CAP(d): cid 0x004f len 22 [psm 1]
SDP SSA Req: tid 0x4 len 0x11
pat uuid-16 0x1124 (HID)
max 0xffff
aid(s) 0x0000 - 0xffff
cont 02 01 62
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 17
> ACL data: handle 0x002f flags 0x01 dlen 4
L2CAP(d): cid 0x0042 len 17 [psm 1]
SDP SSA Rsp: tid 0x4 len 0xc
cnt 0x9
ERROR: Unexpected syntax
0000: 0d 28 01 09 02 0e 28 01 00
.(....(..
cont 0D 28 01 09 02 0E 28 01 00
< ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x004f scid 0x0042
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x004f scid 0x0042
> HCI Event: Mode Change (0x14) plen 6
0000: 00 2f 00 02 14 00 ./....
< ACL data: handle 0x002f flags 0x02 dlen 15
L2CAP(d): cid 0x004e len 11 [psm 19]
HIDP: Data: Output report
0000: 01 00 00 00 00 00 00 00 00 80 ..........
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 2f 00 01 00 ./...
> ACL data: handle 0x002f flags 0x02 dlen 5
L2CAP(d): cid 0x0040 len 1 [psm 17]
HIDP: Handshake: Unsupported request
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 58 00 00 00 00 00 ...X.....
> ACL data: handle 0x002f flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
0000: 01 00 00 00 00 00 00 00 00 .........
relevant dmesg output:
PCI: Enabling device 0002:06:0e.0 (0000 -> 0002)
ohci1394: fw-host0: Unexpected PCI resource length of 1000!
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[40]
MMIO=[f5000000-f50007ff] Max Packet=[4096]
usb 3-1: new full speed USB device using address 4
hub 3-1:1.0: USB hub found
hub 3-1:1.0: 2 ports detected
usb 2-1.2: new low speed USB device using address 5
input: USB HID v1.00 Mouse [4D Mouse USB Mouse] on usb-0001:01:1b.0-1.2
ieee1394: Host added: ID:BUS[0-00:1023] GUID[000d93fffe436326]
usb 3-1.1: new full speed USB device using address 5
input: USB HID v1.10 Keyboard [BTC Multimedia USB Keyboard] on
usb-0001:01:1b.1-1.1
ip1394: $Rev: 1224 $ Ben Collins <[email protected]>
divert: not allocating divert_blk for non-ethernet device eth1
ip1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
ip1394: eth1: Could not allocate isochronous receive context for the
broadcast channel
ipt_recent v0.3.1: Stephen Frost <[email protected]>.
http://snowman.net/projects/ipt_recent/
PHY ID: 1410cc1, addr: 0
eth0: Link is up at 100 Mbps, full-duplex.
eth0: Pause is disabled
hda: Set PIO timing for mode 0, reg: 0x08618a92
usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0
ret -110
usb 1-1: USB disconnect, address 2
drivers/usb/input/hid-core.c: can't resubmit intr,
0001:01:1a.0-1/input0, status -19
drivers/usb/input/hid-core.c: can't resubmit intr,
0001:01:1a.0-1/input1, status -19
usb 1-1: new full speed USB device using address 3
drivers/usb/input/hid-input.c: event field not found
net/bluetooth/hidp/hid.c: event field not found
/etc/bluetooth/hcid.conf:
#
# HCI daemon configuration file.
#
# $Id: hcid.conf,v 1.4 2004/04/29 20:14:21 holtmann Exp $
#
# HCId options
options {
# Automatically initialize new devices
autoinit yes;
# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security auto;
# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;
# PIN helper
pin_helper /usr/local/bin/bluepin;
# D-Bus PIN helper
#dbus_pin_helper;
}
# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";
# Local device class
class 0x100;
# Default packet type
#pkt_type DH1,DM1,HV1;
# Inquiry and Page scan
iscan enable; pscan enable;
# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
#
#lm accept,master;
#
lm accept;
# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
#
#lp hold,sniff;
#
lp rswitch,hold,sniff,park;
# Authentication and Encryption
#auth enable;
#encrypt enable;
}
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Marcel,
I will get the Apple bluetooth properly fixed over the next few weeks.
My experience with commercial router development on DECnet, TCP/IP and
OSPF routing and Linux network device drivers will be very useful here.
Things are working enough to show that there is not that much wrong.
Just needs a few hours getting familiar with the code, BT protocols,
and fixing the bugs.
Pretty busy these next few weeks, so it may take some time. Could you
please give me a few pointers to find CVS/Bitkeeper stuff, and protocol
specs/docs?
Cheers,
Matthew Grant
On 25/10/2004, at 9:59 PM, Matthew Grant wrote:
> Marcel,
>
> Back in OS X to get this posted. Wish I had linux BT going enough so
> that I could easily use the keyboard which I am bound to because of
> RSI reasons.
>
> There is definitely more to the Apple bluetooth than the bluez-utils
> can interface with. It looks like Apple have changed the CSR firmware
> so that they can turn the USB BT dongle on and off for going on
> aeroplanes, and there is something with the commands to delete and add
> parings that is different as well. Bluez does not look like it is
> doing this.
>
> 'hidd --show' does not list any devices, even when 'hcitool con' lists
> authed encrypted parings. 'hidd --killall' does not work, and 'hidd
> --kill <BT-mac>' does kill off the pairing
>
> I went back into OS X and deleting the pairings there, rebooted back
> to linux, reformed the pairings using 'hidd --search' , 'hidd --show'
> didn't list anything. Rebooted from linux to linux again, and the
> keyboard did not connect. When rebooting to OS X there were no
> parings showing either. Maybe I should not mix them, but I need to
> get linux working fully with this onboard apple BT dongle so that I
> can use linux on this laptop.
>
> Does hidd save pairings to disk somewhere? I am wondering if OS X is
> doing this in addition to the flash on the built-in USB dongle.
>
> Anyone else have experience with Apple powerbooks/keyboards, and Bluez
> HID stuff?
>
> Thanks for all your help.
>
> Cheers,
>
> Matthew Grant
>
> On 25/10/2004, at 4:55 PM, Marcel Holtmann wrote:
>
>>> The Lower level layer is definitely connected, but the keyboard
>>> events
>>> are not generating keyboard input at all. I have to switch the
>>> keyboard
>>> off, and then switch it back on, and it renegotiates, and it all
>>> starts
>>> working.
>>
>> What does "hidd --show" tell you when the keyboard is connected, but
>> not
>> working?
>
> It does not show anything.
>
>
>>> This test is not using security mode 3 yet, though I will be doing
>>> this
>>> to prevent people sniffing passwords.... but the same problem happens
>>> then.
>>
>> Actually I thought, that the Apple keyboard is always in security mode
>> three, but from your dumps it looks like that this is not true when it
>> reconnects. What does "hcitool con" say about the reconnect ACL link?
>>
>>> When I boot from OS X back into Linux, the problem does not occur.
>>
>> This is strange and actually I never had any problems with the Apple
>> HID
>> stuff, but I used it on a normal Intel machine.
>>
>> Regards
>>
>> Marcel
>>
>>
>>
Marcel,
Back in OS X to get this posted. Wish I had linux BT going enough so
that I could easily use the keyboard which I am bound to because of RSI
reasons.
There is definitely more to the Apple bluetooth than the bluez-utils
can interface with. It looks like Apple have changed the CSR firmware
so that they can turn the USB BT dongle on and off for going on
aeroplanes, and there is something with the commands to delete and add
parings that is different as well. Bluez does not look like it is
doing this.
'hidd --show' does not list any devices, even when 'hcitool con' lists
authed encrypted parings. 'hidd --killall' does not work, and 'hidd
--kill <BT-mac>' does kill off the pairing
I went back into OS X and deleting the pairings there, rebooted back to
linux, reformed the pairings using 'hidd --search' , 'hidd --show'
didn't list anything. Rebooted from linux to linux again, and the
keyboard did not connect. When rebooting to OS X there were no parings
showing either. Maybe I should not mix them, but I need to get linux
working fully with this onboard apple BT dongle so that I can use linux
on this laptop.
Does hidd save pairings to disk somewhere? I am wondering if OS X is
doing this in addition to the flash on the built-in USB dongle.
Anyone else have experience with Apple powerbooks/keyboards, and Bluez
HID stuff?
Thanks for all your help.
Cheers,
Matthew Grant
On 25/10/2004, at 4:55 PM, Marcel Holtmann wrote:
>> The Lower level layer is definitely connected, but the keyboard events
>> are not generating keyboard input at all. I have to switch the
>> keyboard
>> off, and then switch it back on, and it renegotiates, and it all
>> starts
>> working.
>
> What does "hidd --show" tell you when the keyboard is connected, but
> not
> working?
It does not show anything.
>> This test is not using security mode 3 yet, though I will be doing
>> this
>> to prevent people sniffing passwords.... but the same problem happens
>> then.
>
> Actually I thought, that the Apple keyboard is always in security mode
> three, but from your dumps it looks like that this is not true when it
> reconnects. What does "hcitool con" say about the reconnect ACL link?
>
>> When I boot from OS X back into Linux, the problem does not occur.
>
> This is strange and actually I never had any problems with the Apple
> HID
> stuff, but I used it on a normal Intel machine.
>
> Regards
>
> Marcel
>
>
>
Hi Matthew,
> If it would be useful, I can get a dump of Apple OSX doing its BT stuff
> on boot.
and how would you do that?
> I have a Logitech MX 900 BT base station which I can connect to another
> Linux box. Will hcidump on this be able to dump the conversation if I
> switch off encryption?
The hcidump tool is not an air sniffer.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Matthew,
> Running 2.6.8 mh2, bluz-utils 2.10 on Debian Sarge. Marcel, please
> excuse me for mailing you directly as wellas the list, as I want to send
> you a binary hcidump output so you can get maximum debug info.
don't care about that. If you exceed the mailing list limited I will
accept the post manually and let it through.
> I am having problems with the keyboard not reconnecting on reboot when
> hciattach switches the internal dongle from USB HID emulation to HCI.
It is not hciattach that is switching, it is hid2hci.
> The Lower level layer is definitely connected, but the keyboard events
> are not generating keyboard input at all. I have to switch the keyboard
> off, and then switch it back on, and it renegotiates, and it all starts
> working.
What does "hidd --show" tell you when the keyboard is connected, but not
working?
> This test is not using security mode 3 yet, though I will be doing this
> to prevent people sniffing passwords.... but the same problem happens
> then.
Actually I thought, that the Apple keyboard is always in security mode
three, but from your dumps it looks like that this is not true when it
reconnects. What does "hcitool con" say about the reconnect ACL link?
> When I boot from OS X back into Linux, the problem does not occur.
This is strange and actually I never had any problems with the Apple HID
stuff, but I used it on a normal Intel machine.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi!
If it would be useful, I can get a dump of Apple OSX doing its BT stuff
on boot.
I have a Logitech MX 900 BT base station which I can connect to another
Linux box. Will hcidump on this be able to dump the conversation if I
switch off encryption?
Cheers,
Matthew
On Mon, 2004-10-25 at 10:45, Matthew Grant wrote:
> Hi!
>
> Running 2.6.8 mh2, bluz-utils 2.10 on Debian Sarge. Marcel, please
> excuse me for mailing you directly as wellas the list, as I want to send
> you a binary hcidump output so you can get maximum debug info.
>
> I am having problems with the keyboard not reconnecting on reboot when
> hciattach switches the internal dongle from USB HID emulation to HCI.
>
> The Lower level layer is definitely connected, but the keyboard events
> are not generating keyboard input at all. I have to switch the keyboard
> off, and then switch it back on, and it renegotiates, and it all starts
> working.
>
> This test is not using security mode 3 yet, though I will be doing this
> to prevent people sniffing passwords.... but the same problem happens
> then.
>
> When I boot from OS X back into Linux, the problem does not occur.
>
> I have attached the hcidump binary session data so that you can all look
> at it. If it does not turn up on the mailing list, please email me to
> send it to you. My hcid.conf is included down the bottom.
>
> Here is the screen session I did when playing with keyboard, while using
> an ordinary USB keyboard:
>
> root@sharon:/home/grantma#
> # hcitool con
> Connections:
> > ACL 00:0A:95:3B:0B:49 handle 46 state 1 lm MASTER
>
> root@sharon:/home/grantma#
> # hcitool dc 00:0A:95:3B:0B:49
> Disconnect failed: Connection timed out
>
> root@sharon:/home/grantma#
> # hcitool dc 00:0A:95:3B:0B:49
> Not connected.
>
> root@sharon:/home/grantma#
> # hcitool con
> Connections:
>
> root@sharon:/home/grantma#
> # hcitool con
> Connections:
> > ACL 00:0A:95:3B:0B:49 handle 47 state 1 lm MASTER
>
> root@sharon:/home/grantma#
> # hcitool con
> Connections:
> > ACL 00:0A:95:3B:0B:49 handle 47 state 1 lm MASTER
>
> root@sharon:/home/grantma#
> #
>
> This is the output of hcidump 1.12 (hcidump -X) when I start trying to
> use the keyboard:
>
> HCIDump - HCI packet analyzer ver 1.12
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 00 00 00 00 00 00 ..........
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 00 00 00 00 00 00 ..........
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 00 00 00 00 00 00 ..........
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 00 00 00 00 00 00 ..........
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 00 00 00 00 00 00 ..........
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 58 00 00 00 00 00 ....X.....
> > ACL data: handle 0x002e flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 0]
> 0000: a1 01 00 00 00 00 00 00 00 00 ..........
> < HCI Command: Disconnect (0x01|0x0006) plen 3
> 0000: 2e 00 13 ...
> > HCI Event: Command Status (0x0f) plen 4
> 0000: 00 01 06 04 ....
> > HCI Event: Disconn Complete (0x05) plen 4
> 0000: 00 2e 00 16 ....
> > HCI Event: Connect Request (0x04) plen 10
> 0000: 49 0b 3b 95 0a 00 40 25 00 01 I.;...@%..
> < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> 0000: 49 0b 3b 95 0a 00 00 I.;....
> > HCI Event: Command Status (0x0f) plen 4
> 0000: 00 01 09 04 ....
> > HCI Event: Role Change (0x12) plen 8
> 0000: 00 49 0b 3b 95 0a 00 00 .I.;....
> > HCI Event: Connect Complete (0x03) plen 11
> 0000: 00 2f 00 49 0b 3b 95 0a 00 01 00 ./.I.;.....
> < HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
> 0000: 2f 00 0f 00 /...
> > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
> 0000: 49 0b 3b 95 0a 00 01 I.;....
> > ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 17 scid 0x004d
> < ACL data: handle 0x002f flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x004d result 0 status 0
> > HCI Event: Command Complete (0x0e) plen 6
> 0000: 01 0d 08 00 2f 00 ..../.
> < HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
> 0000: 2f 00 18 cc /...
> > HCI Event: Command Status (0x0f) plen 4
> 0000: 00 01 0f 04 ....
> > HCI Event: Connection Packet Type Changed (0x1d) plen 5
> 0000: 00 2f 00 18 00 ./...
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0
> < ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x004d flags 0x0000 result 0 clen 0
> < ACL data: handle 0x002f flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x004d flags 0x0000 clen 4
> MTU 48
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 1
> L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 4
> MTU 48
> > ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 19 scid 0x004e
> < ACL data: handle 0x002f flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0041 scid 0x004e result 0 status 0
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 0
> < ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x004e flags 0x0000 result 0 clen 0
> < ACL data: handle 0x002f flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x004e flags 0x0000 clen 4
> MTU 48
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 1
> L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 4
> MTU 48
> < ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 1 scid 0x0042
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x004f scid 0x0042 result 0 status 0
> < ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Config req: dcid 0x004f flags 0x0000 clen 0
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > HCI Event: Mode Change (0x14) plen 6
> 0000: 00 2f 00 02 14 00 ./....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x0042 flags 0x0000 result 0 clen 0
> > ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Config req: dcid 0x0042 flags 0x0000 clen 0
> < ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x004f flags 0x0000 result 0 clen 0
> < ACL data: handle 0x002f flags 0x02 dlen 24
> L2CAP(d): cid 0x004f len 20 [psm 1]
> SDP SSA Req: tid 0x0 len 0xf
> pat uuid-16 0x1200 (PNPInfo)
> max 0xffff
> aid(s) 0x0000 - 0xffff
> cont 00
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 15
> L2CAP(d): cid 0x0042 len 96 [psm 1]
> SDP SSA Rsp: tid 0x0 len 0x5b
> cnt 0x58
> srv rec #0
> aid 0x0000 (SrvRecHndl)
> uint 0x10001
> aid 0x0001 (SrvClassIDList)
> < uuid-16 0x1200 (PNPInfo) >
> aid 0x0004 (ProtocolDescList)
> < < uuid-16 0x0100 (L2CAP) uint 0x1 > <
> uuid-16 0x0001 (SDP) > >
> aid 0x0009 (BTProfileDescList)
> < < uuid-16 0x1200 (PNPInfo) uint 0x100 > >
> aid 0x0200 (VersionNumList)
> uint 0x100
> aid 0x0201 (SrvDBState)
> uint 0x5ac
> aid 0x0202 (unknown)
> uint 0x208
> aid 0x0203 (unknown)
> uint 0x110
> aid 0x0204 (unknown)
> bool 0x1
> aid 0x0205 (unknown)
> uint 0x2
>
> cont 00
> < ACL data: handle 0x002f flags 0x02 dlen 24
> L2CAP(d): cid 0x004f len 20 [psm 1]
> SDP SSA Req: tid 0x1 len 0xf
> pat uuid-16 0x1124 (HID)
> max 0xffff
> aid(s) 0x0000 - 0xffff
> cont 00
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > HCI Event: Mode Change (0x14) plen 6
> 0000: 00 2f 00 00 00 00 ./....
> > ACL data: handle 0x002f flags 0x02 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 13
> L2CAP(d): cid 0x0042 len 128 [psm 1]
> SDP SSA Rsp: tid 0x1 len 0x7b
> cnt 0x76
> srv rec #0
> aid 0x0000 (SrvRecHndl)
> uint 0x10000
> aid 0x0001 (SrvClassIDList)
> < uuid-16 0x1124 (HID) >
> aid 0x0004 (ProtocolDescList)
> < < uuid-16 0x0100 (L2CAP) uint 0x11 > <
> uuid-16 0x0011 (HIDP) > >
> aid 0x0005 (BrwGrpList)
> < uuid-16 0x1002 (PubBrwsGrp) >
> aid 0x0006 (LangBaseAttrIDList)
> < uint 0x656e uint 0x6a uint 0x100 >
> aid 0x0009 (BTProfileDescList)
> < < uuid-16 0x1124 (HID) uint 0x100 > >
> aid 0x000d (IconURL)
> < < < uuid-16 0x0100 (L2CAP) uint 0x13 > < uuid-16 0x0011
> (HIDP) > > >
> aid 0x0100 (SrvName)
> str "Apple Wireless Key"
>
> cont
> < ACL data: handle 0x002f flags 0x02 dlen 26
> L2CAP(d): cid 0x004f len 22 [psm 1]
> SDP SSA Req: tid 0x2 len 0x11
> pat uuid-16 0x1124 (HID)
> max 0xffff
> aid(s) 0x0000 - 0xffff
> cont 02 00 76
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 13
> L2CAP(d): cid 0x0042 len 128 [psm 1]
> SDP SSA Rsp: tid 0x2 len 0x7b
> cnt 0x76
>
> ERROR: Unexpected syntax
> 0000: 6f 61 72 64 09 01 01 25 17 41 70 70 6c 65 20 57
> oard...%.Apple W
> 0010: 69 72 65 6c 65 73 73 20 4b 65 79 62 6f 61 72 64
> ireless Keyboard
> 0020: 09 01 02 25 14 41 70 70 6c 65 20 43 6f 6d 70 75
> ...%.Apple Compu
> 0030: 74 65 72 2c 20 49 6e 63 2e 09 02 00 09 01 10 09 ter,
> Inc........
> 0040: 02 01 09 01 11 09 02 02 08 40 09 02 03 08 21 09
> .........@....!.
> 0050: 02 04 28 01 09 02 05 28 01 09 02 06 35 69 35 67
> ..(....(....5i5g
> 0060: 08 22 25 63 05 01 09 06 a1 01 85 01 05 07 19 e0
> ."%c............
> 0070: 29 e7 15 00 25 02 00 ec
> )...%...
> cont 6F 61 72 64 09 01 01 25 17 41 70 70 6C 65 20 57 69 72 65
> 6C 65 73 73 20 4B 65 79 62 6F 61 72 64 09 01 02 25 14 41 70 70 6C 65 20
> 43 6F 6D 70 75 74 65 72 2C 20 49 6E 63 2E 09 02 00 09 01 10 09 02 01 09
> 01 11 09 02 02 08 40 09 02 03 08 21 09 02 04 28 01 09 02 05 28 01 09 02
> 06 35 69 35 67 08 22 25 63 05 01 09 06 A1 01 85 01 05 07 19 E0 29 E7 15
> 00 25 02 00 EC
> < ACL data: handle 0x002f flags 0x02 dlen 26
> L2CAP(d): cid 0x004f len 22 [psm 1]
> SDP SSA Req: tid 0x3 len 0x11
> pat uuid-16 0x1124 (HID)
> max 0xffff
> aid(s) 0x0000 - 0xffff
> cont 02 00 EC
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 13
> L2CAP(d): cid 0x0042 len 128 [psm 1]
> SDP SSA Rsp: tid 0x3 len 0x7b
> cnt 0x76
>
> ERROR: Unexpected syntax
> 0000: 75 01 95 08 81 02 75 08 95 01 81 01 75 01 95 05
> u.....u.....u...
> 0010: 05 08 19 01 29 05 91 02 75 03 95 01 91 01 75 08
> ....)...u.....u.
> 0020: 95 06 15 00 26 ff 00 05 07 19 00 2a ff 00 81 00
> ....&......*....
> 0030: 75 01 95 01 15 00 25 01 05 0c 09 b8 81 06 09 e2
> u.....%.........
> 0040: 81 06 09 e9 81 02 09 ea 81 02 75 01 95 04 81 01
> ..........u.....
> 0050: c0 09 02 07 35 08 35 06 09 04 09 09 01 00 09 02
> ....5.5.........
> 0060: 08 28 00 09 02 0a 28 01 09 02 0b 09 01 00 09 02
> .(....(.........
> 0070: 0c 09 1f 40 09 02 01 62
> [email protected]
> cont 75 01 95 08 81 02 75 08 95 01 81 01 75 01 95 05 05 08 19
> 01 29 05 91 02 75 03 95 01 91 01 75 08 95 06 15 00 26 FF 00 05 07 19 00
> 2A FF 00 81 00 75 01 95 01 15 00 25 01 05 0C 09 B8 81 06 09 E2 81 06 09
> E9 81 02 09 EA 81 02 75 01 95 04 81 01 C0 09 02 07 35 08 35 06 09 04 09
> 09 01 00 09 02 08 28 00 09 02 0A 28 01 09 02 0B 09 01 00 09 02 0C 09 1F
> 40 09 02 01 62
> < ACL data: handle 0x002f flags 0x02 dlen 26
> L2CAP(d): cid 0x004f len 22 [psm 1]
> SDP SSA Req: tid 0x4 len 0x11
> pat uuid-16 0x1124 (HID)
> max 0xffff
> aid(s) 0x0000 - 0xffff
> cont 02 01 62
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 17
> > ACL data: handle 0x002f flags 0x01 dlen 4
> L2CAP(d): cid 0x0042 len 17 [psm 1]
> SDP SSA Rsp: tid 0x4 len 0xc
> cnt 0x9
>
> ERROR: Unexpected syntax
> 0000: 0d 28 01 09 02 0e 28 01 00
> .(....(..
> cont 0D 28 01 09 02 0E 28 01 00
> < ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Disconn req: dcid 0x004f scid 0x0042
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x004f scid 0x0042
> > HCI Event: Mode Change (0x14) plen 6
> 0000: 00 2f 00 02 14 00 ./....
> < ACL data: handle 0x002f flags 0x02 dlen 15
> L2CAP(d): cid 0x004e len 11 [psm 19]
> HIDP: Data: Output report
> 0000: 01 00 00 00 00 00 00 00 00 80 ..........
> > HCI Event: Number of Completed Packets (0x13) plen 5
> 0000: 01 2f 00 01 00 ./...
> > ACL data: handle 0x002f flags 0x02 dlen 5
> L2CAP(d): cid 0x0040 len 1 [psm 17]
> HIDP: Handshake: Unsupported request
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 58 00 00 00 00 00 ...X.....
> > ACL data: handle 0x002f flags 0x02 dlen 14
> L2CAP(d): cid 0x0041 len 10 [psm 19]
> HIDP: Data: Input report
> 0000: 01 00 00 00 00 00 00 00 00 .........
>
>
> relevant dmesg output:
>
> PCI: Enabling device 0002:06:0e.0 (0000 -> 0002)
> ohci1394: fw-host0: Unexpected PCI resource length of 1000!
> ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[40]
> MMIO=[f5000000-f50007ff] Max Packet=[4096]
> usb 3-1: new full speed USB device using address 4
> hub 3-1:1.0: USB hub found
> hub 3-1:1.0: 2 ports detected
> usb 2-1.2: new low speed USB device using address 5
> input: USB HID v1.00 Mouse [4D Mouse USB Mouse] on usb-0001:01:1b.0-1.2
> ieee1394: Host added: ID:BUS[0-00:1023] GUID[000d93fffe436326]
> usb 3-1.1: new full speed USB device using address 5
> input: USB HID v1.10 Keyboard [BTC Multimedia USB Keyboard] on
> usb-0001:01:1b.1-1.1
> ip1394: $Rev: 1224 $ Ben Collins <[email protected]>
> divert: not allocating divert_blk for non-ethernet device eth1
> ip1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
> ip1394: eth1: Could not allocate isochronous receive context for the
> broadcast channel
> ipt_recent v0.3.1: Stephen Frost <[email protected]>.
> http://snowman.net/projects/ipt_recent/
> PHY ID: 1410cc1, addr: 0
> eth0: Link is up at 100 Mbps, full-duplex.
> eth0: Pause is disabled
> hda: Set PIO timing for mode 0, reg: 0x08618a92
> usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0
> ret -110
> usb 1-1: USB disconnect, address 2
> drivers/usb/input/hid-core.c: can't resubmit intr,
> 0001:01:1a.0-1/input0, status -19
> drivers/usb/input/hid-core.c: can't resubmit intr,
> 0001:01:1a.0-1/input1, status -19
> usb 1-1: new full speed USB device using address 3
> drivers/usb/input/hid-input.c: event field not found
> net/bluetooth/hidp/hid.c: event field not found
>
>
> /etc/bluetooth/hcid.conf:
>
> #
> # HCI daemon configuration file.
> #
> # $Id: hcid.conf,v 1.4 2004/04/29 20:14:21 holtmann Exp $
> #
>
> # HCId options
> options {
> # Automatically initialize new devices
> autoinit yes;
>
> # Security Manager mode
> # none - Security manager disabled
> # auto - Use local PIN for incoming connections
> # user - Always ask user for a PIN
> #
> security auto;
>
> # Pairing mode
> # none - Pairing disabled
> # multi - Allow pairing with already paired devices
> # once - Pair once and deny successive attempts
> pairing multi;
>
> # PIN helper
> pin_helper /usr/local/bin/bluepin;
>
> # D-Bus PIN helper
> #dbus_pin_helper;
> }
>
> # Default settings for HCI devices
> device {
> # Local device name
> # %d - device id
> # %h - host name
> name "%h-%d";
>
> # Local device class
> class 0x100;
>
> # Default packet type
> #pkt_type DH1,DM1,HV1;
>
> # Inquiry and Page scan
> iscan enable; pscan enable;
>
> # Default link mode
> # none - no specific policy
> # accept - always accept incoming connections
> # master - become master on incoming connections,
> # deny role switch on outgoing connections
> #
> #lm accept,master;
> #
> lm accept;
>
> # Default link policy
> # none - no specific policy
> # rswitch - allow role switch
> # hold - allow hold mode
> # sniff - allow sniff mode
> # park - allow park mode
> #
> #lp hold,sniff;
> #
> lp rswitch,hold,sniff,park;
>
> # Authentication and Encryption
> #auth enable;
> #encrypt enable;
> }
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Hi Matthew,
> So the policy is not to produce 2.11.1 unless it is more serious than
> this?
if I would do another release it would be 2.12 and not 2.11.1, because I
don't use extra or sublevel release numbers. From my point it is the job
of the package maintainer to backport patches and Edd has proven to be
very good at it.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users/listinfo/bluez-users
Marcel,
Thanks for getting back so quick!
So the policy is not to produce 2.11.1 unless it is more serious than
this?
Cheers,
Matthew Grant
On Sun, 2004-11-14 at 08:05, Marcel Holtmann wrote:
> Hi Matthew,
>
> > Actually, maybe could a new release should be done for this? It fixes a
> > lot of boot script problems on big-endian systems with things not being
> > shutdown properly for hidd. I have observed that not having BT
> > connections cleanly closed off upsets my Apple keyboards.
>
> you are two days too late. I just released a new library version and
> there are other things that should be done first before I will release
> another version. However I think Edd will include the fix in the Debian
> package and this should be enough.
>
> Regards
>
> Marcel
>
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Hi Matthew,
> Actually, maybe could a new release should be done for this? It fixes a
> lot of boot script problems on big-endian systems with things not being
> shutdown properly for hidd. I have observed that not having BT
> connections cleanly closed off upsets my Apple keyboards.
you are two days too late. I just released a new library version and
there are other things that should be done first before I will release
another version. However I think Edd will include the fix in the Debian
package and this should be enough.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users/listinfo/bluez-users
Hi Marcel,
Actually, maybe could a new release should be done for this? It fixes a
lot of boot script problems on big-endian systems with things not being
shutdown properly for hidd. I have observed that not having BT
connections cleanly closed off upsets my Apple keyboards.
Cheers,
Matthew Grant
On Sun, 2004-11-14 at 01:53, Marcel Holtmann wrote:
> Hi Matthew,
>
> > Real reason for it is this, user-space thinks cnum field is 16 bit, kernel
> > thinks it is 32 bit. Bug only shows up in big-endian architectures as result
> > count is returned in top byte of what is received from the kernel, whereas on
> > i386 it is in the lowest where by fluke it works...
> >
> > Mismatch in the kernel and user-space header files:
> >
> > in the kernel, net/bluetooth/hid/hdip.h:
> >
> > struct hidp_connlist_req {
> > __u32 cnum;
> > struct hidp_conninfo __user *ci;
> > };
> >
> > in libbluetoth, include/bluetooth/hidp.h:
> >
> > struct hidp_connlist_req {
> > uint16_t cnum;
> > struct hidp_conninfo *ci;
> > };
> >
> > Which way should we go here? We need to fix kernel or user-space, and I need your
> > 'official' touch before I post a patch in the Debian bug report I am going to submit.
> > The fix I prefer affects the user-space bluetooth include files.
>
> thanks for finding this mismatch. We change the userspace, because the
> kernel interface should stay stable. Actually I looked also at BNEP and
> CMTP and found that we have the same problem in CMTP. So I must have
> done this wrong in the early days of CMTP and then copied over to HIDP.
> A patch for this is in the CVS now.
>
> Regards
>
> Marcel
>
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Hi Matthew,
> Real reason for it is this, user-space thinks cnum field is 16 bit, kernel
> thinks it is 32 bit. Bug only shows up in big-endian architectures as result
> count is returned in top byte of what is received from the kernel, whereas on
> i386 it is in the lowest where by fluke it works...
>
> Mismatch in the kernel and user-space header files:
>
> in the kernel, net/bluetooth/hid/hdip.h:
>
> struct hidp_connlist_req {
> __u32 cnum;
> struct hidp_conninfo __user *ci;
> };
>
> in libbluetoth, include/bluetooth/hidp.h:
>
> struct hidp_connlist_req {
> uint16_t cnum;
> struct hidp_conninfo *ci;
> };
>
> Which way should we go here? We need to fix kernel or user-space, and I need your
> 'official' touch before I post a patch in the Debian bug report I am going to submit.
> The fix I prefer affects the user-space bluetooth include files.
thanks for finding this mismatch. We change the userspace, because the
kernel interface should stay stable. Actually I looked also at BNEP and
CMTP and found that we have the same problem in CMTP. So I must have
done this wrong in the early days of CMTP and then copied over to HIDP.
A patch for this is in the CVS now.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users/listinfo/bluez-users
Hi Marcel,
My first ideas about the kernel realigning things are wrong, its actually the
struct hidp_connlist_req definitions not matching.
Real reason for it is this, user-space thinks cnum field is 16 bit, kernel
thinks it is 32 bit. Bug only shows up in big-endian architectures as result
count is returned in top byte of what is received from the kernel, whereas on
i386 it is in the lowest where by fluke it works...
Mismatch in the kernel and user-space header files:
in the kernel, net/bluetooth/hid/hdip.h:
struct hidp_connlist_req {
__u32 cnum;
struct hidp_conninfo __user *ci;
};
in libbluetoth, include/bluetooth/hidp.h:
struct hidp_connlist_req {
uint16_t cnum;
struct hidp_conninfo *ci;
};
Which way should we go here? We need to fix kernel or user-space, and I need your
'official' touch before I post a patch in the Debian bug report I am going to submit.
The fix I prefer affects the user-space bluetooth include files.
My inclination is to convert user space from uint16_t
to uint32_t for the cnum field as this will properly byte-align the following pointer
on a 4-byte boundary. Some architectures throw exceptions on non-aligned pointer
dereferences and accesses, and this is why I suspect the kernel may have been changed.
Cheers,
Matthew Grant
PS: Following is here for reference.
Found what is wrong with hidd --show on powerpc.
In function do_show(), main.c, hidd
The kernel is converting the size of the cnum record entry of struct
hidp_connlist_req from 2 bytes to 4, probably in an attempt to align the
pointer on a 4 byte boundary. The program has not been compiled to take
account of this and thinks req.cnum is zero.... If this happens on Intel
it would not show up as the returned count would be written into the
first byte of the returned 4 byte integer... I don't know what effect
this would be having on the programs stack, but more than 15 BT
connections could result in a buffer overflow.
Need to change cnum field of struct hidp_connlist_req to a uint32 to
stop this, and it should all start working...
gdb session output follows.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/src/bluetooth/debug/bluez-utils-2.11/hidd/hidd
--show
Breakpoint 1, do_show (ctl=7) at main.c:364
364 printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) n
361 req.cnum = 16;
(gdb) n
355 {
(gdb) n
362 req.ci = ci;
(gdb) n
364 printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) n
do_show(): req.cnum 16, req.ci 0x7fffedd0
365 if (ioctl(ctl, HIDPGETCONNLIST, &req) < 0) {
(gdb) x/8xb 0x7ffff730
0x7ffff730: 0x00 0x10 0xf7 0x70 0x7f 0xff 0xed
0xd0
(gdb) n
371 printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) x/8xb 0x7ffff730
0x7ffff730: 0x00 0x00 0x00 0x01 0x7f 0xff 0xee
0x64
(gdb)
Cheers,
Matthew Grant
On Tue, 2004-11-09 at 08:53, Marcel Holtmann wrote:
> Hi Matthew,
>
> > Just got debug going. Going to put printks into hidp_get_connlist to
> > see what is happening.
> >
> > Your comment on the big endian bug in the L2CAP you noticed below, and
> > some of the debug I have seen with the other BT problems make it look
> > like I am having endianess issues.
> >
> > I am going to print the kernel code tonight and read it through as it is
> > obvious I have to understand the stack if I am get things fixed - you
> > don't have access to an Apple machine to test things on. In the past I
> > was a commercial router programmer, doing OSPF and IPX development.
> >
> > Any good places to find protocol specs? I especially need
> > specifications on the endianess of the incoming BT data so I can audit
> > and check the debug for that sort of thing.
>
> everything is in the Bluetooth core and HID profile specification.
>
> It must not be an endian problem, because other people with Apple
> machines are using HID. May you wanna try another compiler.
>
> Regards
>
> Marcel
>
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Hi Marcel,
Found what is wrong with hidd --show on powerpc.
In function do_show(), main.c, hidd
The kernel is converting the size of the cnum record entry of struct
hidp_connlist_req from 2 bytes to 4, probably in an attempt to align the
pointer on a 4 byte boundary. The program has not been compiled to take
account of this and thinks req.cnum is zero.... If this happens on Intel
it would not show up as the returned count would be written into the
first byte of the returned 4 byte integer... I don't know what effect
this would be having on the programs stack, but more than 15 BT
connections could result in a buffer overflow.
Need to change cnum field of struct hidp_connlist_req to a uint32 to
stop this, and it should all start working...
gdb session output follows.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/src/bluetooth/debug/bluez-utils-2.11/hidd/hidd
--show
Breakpoint 1, do_show (ctl=7) at main.c:364
364 printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) n
361 req.cnum = 16;
(gdb) n
355 {
(gdb) n
362 req.ci = ci;
(gdb) n
364 printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) n
do_show(): req.cnum 16, req.ci 0x7fffedd0
365 if (ioctl(ctl, HIDPGETCONNLIST, &req) < 0) {
(gdb) x/8xb 0x7ffff730
0x7ffff730: 0x00 0x10 0xf7 0x70 0x7f 0xff 0xed
0xd0
(gdb) n
371 printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) x/8xb 0x7ffff730
0x7ffff730: 0x00 0x00 0x00 0x01 0x7f 0xff 0xee
0x64
(gdb)
Cheers,
Matthew Grant
On Tue, 2004-11-09 at 08:53, Marcel Holtmann wrote:
> Hi Matthew,
>
> > Just got debug going. Going to put printks into hidp_get_connlist to
> > see what is happening.
> >
> > Your comment on the big endian bug in the L2CAP you noticed below, and
> > some of the debug I have seen with the other BT problems make it look
> > like I am having endianess issues.
> >
> > I am going to print the kernel code tonight and read it through as it is
> > obvious I have to understand the stack if I am get things fixed - you
> > don't have access to an Apple machine to test things on. In the past I
> > was a commercial router programmer, doing OSPF and IPX development.
> >
> > Any good places to find protocol specs? I especially need
> > specifications on the endianess of the incoming BT data so I can audit
> > and check the debug for that sort of thing.
>
> everything is in the Bluetooth core and HID profile specification.
>
> It must not be an endian problem, because other people with Apple
> machines are using HID. May you wanna try another compiler.
>
> Regards
>
> Marcel
>
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Marcel,
Sorry about the top-posting, but I want to be quick. Tried to get 2.6.9
compiling under powerpc with GCC 2.95, but found that a lot of the PPC
arch source will only compile under GCC 3.3.x System compiler on
Debian Sarge (my laptop ) is GCC 3.3.4.
Will get on with getting the problems traced tonight, and find where
things are going wrong hopefully. Should have a patch after this
weekend.
Cheers,
Matthew
On Tue, 2004-11-09 at 08:53, Marcel Holtmann wrote:
> Hi Matthew,
>
> > Just got debug going. Going to put printks into hidp_get_connlist to
> > see what is happening.
> >
> > Your comment on the big endian bug in the L2CAP you noticed below, and
> > some of the debug I have seen with the other BT problems make it look
> > like I am having endianess issues.
> >
> > I am going to print the kernel code tonight and read it through as it is
> > obvious I have to understand the stack if I am get things fixed - you
> > don't have access to an Apple machine to test things on. In the past I
> > was a commercial router programmer, doing OSPF and IPX development.
> >
> > Any good places to find protocol specs? I especially need
> > specifications on the endianess of the incoming BT data so I can audit
> > and check the debug for that sort of thing.
>
> everything is in the Bluetooth core and HID profile specification.
>
> It must not be an endian problem, because other people with Apple
> machines are using HID. May you wanna try another compiler.
>
> Regards
>
> Marcel
>
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Hi Matthew,
> Just got debug going. Going to put printks into hidp_get_connlist to
> see what is happening.
>
> Your comment on the big endian bug in the L2CAP you noticed below, and
> some of the debug I have seen with the other BT problems make it look
> like I am having endianess issues.
>
> I am going to print the kernel code tonight and read it through as it is
> obvious I have to understand the stack if I am get things fixed - you
> don't have access to an Apple machine to test things on. In the past I
> was a commercial router programmer, doing OSPF and IPX development.
>
> Any good places to find protocol specs? I especially need
> specifications on the endianess of the incoming BT data so I can audit
> and check the debug for that sort of thing.
everything is in the Bluetooth core and HID profile specification.
It must not be an endian problem, because other people with Apple
machines are using HID. May you wanna try another compiler.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users/listinfo/bluez-users
Marcel,
Just got debug going. Going to put printks into hidp_get_connlist to
see what is happening.
Your comment on the big endian bug in the L2CAP you noticed below, and
some of the debug I have seen with the other BT problems make it look
like I am having endianess issues.
I am going to print the kernel code tonight and read it through as it is
obvious I have to understand the stack if I am get things fixed - you
don't have access to an Apple machine to test things on. In the past I
was a commercial router programmer, doing OSPF and IPX development.
Any good places to find protocol specs? I especially need
specifications on the endianess of the incoming BT data so I can audit
and check the debug for that sort of thing.
Cheers,
Matthew Grant
On Sun, 2004-11-07 at 15:38, Marcel Holtmann wrote:
> Hi Matthew,
>
> > > and what does /proc/bluetooth/l2cap show you?
> > >
> >
> > root@sharon:/usr/src/bluetooth/bluez-utils-2.10#
> > # cat /proc/bluetooth/l2cap
> > A7:FF:10:93:0D:00 49:0B:3B:95:0A:00 1 4864 0x0041 0x0041 48 672 0x1
> > A7:FF:10:93:0D:00 49:0B:3B:95:0A:00 1 4352 0x0040 0x0040 48 672 0x1
> > A7:FF:10:93:0D:00 61:DF:16:61:07:00 1 4864 0x0041 0x004d 48 48 0x1
> > A7:FF:10:93:0D:00 61:DF:16:61:07:00 1 4352 0x0040 0x004c 48 48 0x1
> > 00:00:00:00:00:00 00:00:00:00:00:00 4 4864 0x0000 0x0000 48 48 0x1
> > 00:00:00:00:00:00 00:00:00:00:00:00 4 4352 0x0000 0x0000 48 48 0x1
> > 00:00:00:00:00:00 00:00:00:00:00:00 4 256 0x0000 0x0000 672 0 0x0
> > 00:00:00:00:00:00 00:00:00:00:00:00 4 768 0x0000 0x0000 1024 0 0x0
> >
> > The above bluetooth addresses are all in reverse byte order!!!
> >
> > Apple Keyboard is 00:0A:95:3B:0B:49
> > Logitech Mx900 Mouse is 00:07:61:16:DF:61
> > computer hci0 is 00:0D:93:10:FF:A7
>
> the address order is ok, but the column for the PSM has a big endian
> bug. This needs to be fixed.
>
> However you are connected to the mouse and the keyboard. This is
> actually working fine.
>
> > > You can enable the DEBUG in the hidp driver or add some printk calls be
> > > yourself to see where the ioctl fails.
> > >
> > I will give this a go latter on this afternoon.
>
> Try to find the reason why and where the ioctl fails.
>
> Regards
>
> Marcel
>
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Hi Matthew,
> > and what does /proc/bluetooth/l2cap show you?
> >
>
> root@sharon:/usr/src/bluetooth/bluez-utils-2.10#
> # cat /proc/bluetooth/l2cap
> A7:FF:10:93:0D:00 49:0B:3B:95:0A:00 1 4864 0x0041 0x0041 48 672 0x1
> A7:FF:10:93:0D:00 49:0B:3B:95:0A:00 1 4352 0x0040 0x0040 48 672 0x1
> A7:FF:10:93:0D:00 61:DF:16:61:07:00 1 4864 0x0041 0x004d 48 48 0x1
> A7:FF:10:93:0D:00 61:DF:16:61:07:00 1 4352 0x0040 0x004c 48 48 0x1
> 00:00:00:00:00:00 00:00:00:00:00:00 4 4864 0x0000 0x0000 48 48 0x1
> 00:00:00:00:00:00 00:00:00:00:00:00 4 4352 0x0000 0x0000 48 48 0x1
> 00:00:00:00:00:00 00:00:00:00:00:00 4 256 0x0000 0x0000 672 0 0x0
> 00:00:00:00:00:00 00:00:00:00:00:00 4 768 0x0000 0x0000 1024 0 0x0
>
> The above bluetooth addresses are all in reverse byte order!!!
>
> Apple Keyboard is 00:0A:95:3B:0B:49
> Logitech Mx900 Mouse is 00:07:61:16:DF:61
> computer hci0 is 00:0D:93:10:FF:A7
the address order is ok, but the column for the PSM has a big endian
bug. This needs to be fixed.
However you are connected to the mouse and the keyboard. This is
actually working fine.
> > You can enable the DEBUG in the hidp driver or add some printk calls be
> > yourself to see where the ioctl fails.
> >
> I will give this a go latter on this afternoon.
Try to find the reason why and where the ioctl fails.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users/listinfo/bluez-users
Hi Matthew,
> > > Finally figured out what is wrong. There is definitely a Powerpc
> > > problem with the BT HIDPGETCONNLIST ioctl on the powerpc arch.
> > >
> > > The HID ioctl HIDPGETCONNLIST is not returning any HID device entries
> > > from the kernel on the Powerpc architecture, even when a blue-tooth
> > > keyboard and mouse are working.
> > >
> > > In Debian's boot scripts hidd --killall is used to nicely close the
> > > connections so that the devices will reconnect cleanly on next boot.
> > > This is not working for me as the above ioctl is not returning a list if
> > > addresses to be acted on.
> > >
> > > Work around for me will be to explicitly kill each device address before
> > > stopping hidd, as hidd --kill <device address> works. Does this mean
> > > that the devices are registering in the hidp module, but there is a
> > > problem in passing the list back out of the kernel?
> >
> > does "hidd --show" works?
>
> Definitely does not work. The above kernel ioctl appears to be busted
> (or the add HID device stuff is as it is not updating the in kernel HID
> device list). Read the source code for hidd, comparing against strace
> output for "hidd --show". hidd is running as the BT dongle is in HCi
> mode, and I am typing this.
and what does /proc/bluetooth/l2cap show you?
> > > Do you have access to a powerpc machine to test this on? Could you give
> > > me any instructions on getting the hidp.ko module to produce the debug
> > > that would be useful?
> > >
> > > It would be good to get this one solved, as I would like to look at
> > > shallower bugs which I can knock off myself. First look at the hidp code
> > > with this one freaked me out a bit.
> >
> > I don't have access to a PowerPC machine. What Apple is this?
> >
>
> 2004 Powerbook 15" Al, 1.33GHz G4, 768 MB RAM, built-in Apple bluetooth,
> ATI Radeon video.
>
> Also occurs on my 450MHz g3 PowerMac, with Logitech BT dongle...
>
> I could probably give you access and work with you over say IRC or gaim
> in testing this (I have cable with a static IP!), as this is a generic
> powerpc problem, and I can remove sensitive stuff off my G3.
You can enable the DEBUG in the hidp driver or add some printk calls be
yourself to see where the ioctl fails.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users/listinfo/bluez-users
Marcell,
On Sun, 2004-11-07 at 01:34, Marcel Holtmann wrote:
> Hi Matthew,
>
> > Finally figured out what is wrong. There is definitely a Powerpc
> > problem with the BT HIDPGETCONNLIST ioctl on the powerpc arch.
> >
> > The HID ioctl HIDPGETCONNLIST is not returning any HID device entries
> > from the kernel on the Powerpc architecture, even when a blue-tooth
> > keyboard and mouse are working.
> >
> > In Debian's boot scripts hidd --killall is used to nicely close the
> > connections so that the devices will reconnect cleanly on next boot.
> > This is not working for me as the above ioctl is not returning a list if
> > addresses to be acted on.
> >
> > Work around for me will be to explicitly kill each device address before
> > stopping hidd, as hidd --kill <device address> works. Does this mean
> > that the devices are registering in the hidp module, but there is a
> > problem in passing the list back out of the kernel?
>
> does "hidd --show" works?
Definitely does not work. The above kernel ioctl appears to be busted
(or the add HID device stuff is as it is not updating the in kernel HID
device list). Read the source code for hidd, comparing against strace
output for "hidd --show". hidd is running as the BT dongle is in HCi
mode, and I am typing this.
> > Do you have access to a powerpc machine to test this on? Could you give
> > me any instructions on getting the hidp.ko module to produce the debug
> > that would be useful?
> >
> > It would be good to get this one solved, as I would like to look at
> > shallower bugs which I can knock off myself. First look at the hidp code
> > with this one freaked me out a bit.
>
> I don't have access to a PowerPC machine. What Apple is this?
>
2004 Powerbook 15" Al, 1.33GHz G4, 768 MB RAM, built-in Apple bluetooth,
ATI Radeon video.
Also occurs on my 450MHz g3 PowerMac, with Logitech BT dongle...
I could probably give you access and work with you over say IRC or gaim
in testing this (I have cable with a static IP!), as this is a generic
powerpc problem, and I can remove sensitive stuff off my G3.
> Regards
>
> Marcel
>
Regards,
Matthew Grant
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==
Hi Matthew,
> Finally figured out what is wrong. There is definitely a Powerpc
> problem with the BT HIDPGETCONNLIST ioctl on the powerpc arch.
>
> The HID ioctl HIDPGETCONNLIST is not returning any HID device entries
> from the kernel on the Powerpc architecture, even when a blue-tooth
> keyboard and mouse are working.
>
> In Debian's boot scripts hidd --killall is used to nicely close the
> connections so that the devices will reconnect cleanly on next boot.
> This is not working for me as the above ioctl is not returning a list if
> addresses to be acted on.
>
> Work around for me will be to explicitly kill each device address before
> stopping hidd, as hidd --kill <device address> works. Does this mean
> that the devices are registering in the hidp module, but there is a
> problem in passing the list back out of the kernel?
does "hidd --show" works?
> Do you have access to a powerpc machine to test this on? Could you give
> me any instructions on getting the hidp.ko module to produce the debug
> that would be useful?
>
> It would be good to get this one solved, as I would like to look at
> shallower bugs which I can knock off myself. First look at the hidp code
> with this one freaked me out a bit.
I don't have access to a PowerPC machine. What Apple is this?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users/listinfo/bluez-users
Marcel,
Finally figured out what is wrong. There is definitely a Powerpc
problem with the BT HIDPGETCONNLIST ioctl on the powerpc arch.
The HID ioctl HIDPGETCONNLIST is not returning any HID device entries
from the kernel on the Powerpc architecture, even when a blue-tooth
keyboard and mouse are working.
In Debian's boot scripts hidd --killall is used to nicely close the
connections so that the devices will reconnect cleanly on next boot.
This is not working for me as the above ioctl is not returning a list if
addresses to be acted on.
Work around for me will be to explicitly kill each device address before
stopping hidd, as hidd --kill <device address> works. Does this mean
that the devices are registering in the hidp module, but there is a
problem in passing the list back out of the kernel?
Do you have access to a powerpc machine to test this on? Could you give
me any instructions on getting the hidp.ko module to produce the debug
that would be useful?
It would be good to get this one solved, as I would like to look at
shallower bugs which I can knock off myself. First look at the hidp code
with this one freaked me out a bit.
(Eg: like fixing the transfer from USB hid compatibility mode to HCI
mode for the BT Apple keyboard - it seems to get stuck in some mode that
could be fixed by sending it a BT instruction to tell it to reset or
switch modes. The second one is fixing it so that the special Apple
only keys work 100% as expected. Sounds like a simple job of altering
the keymap if an Apple BT keyboard is detected.)
Thanks v. much for all your work and for your help!
Cheers,
Matthew Grant
On Mon, 2004-10-25 at 16:55, Marcel Holtmann wrote:
> Hi Matthew,
>
> > Running 2.6.8 mh2, bluz-utils 2.10 on Debian Sarge. Marcel, please
> > excuse me for mailing you directly as wellas the list, as I want to send
> > you a binary hcidump output so you can get maximum debug info.
>
> don't care about that. If you exceed the mailing list limited I will
> accept the post manually and let it through.
>
> > I am having problems with the keyboard not reconnecting on reboot when
> > hciattach switches the internal dongle from USB HID emulation to HCI.
>
> It is not hciattach that is switching, it is hid2hci.
>
> > The Lower level layer is definitely connected, but the keyboard events
> > are not generating keyboard input at all. I have to switch the keyboard
> > off, and then switch it back on, and it renegotiates, and it all starts
> > working.
>
> What does "hidd --show" tell you when the keyboard is connected, but not
> working?
>
> > This test is not using security mode 3 yet, though I will be doing this
> > to prevent people sniffing passwords.... but the same problem happens
> > then.
>
> Actually I thought, that the Apple keyboard is always in security mode
> three, but from your dumps it looks like that this is not true when it
> reconnects. What does "hcitool con" say about the reconnect ACL link?
>
> > When I boot from OS X back into Linux, the problem does not occur.
>
> This is strange and actually I never had any problems with the Apple HID
> stuff, but I used it on a normal Intel machine.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
--
===============================================================================
Matthew Grant /\ ^/\^ [email protected] /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==