ext Nick Pelly wrote:
This original commit drops an L2CAP or RFCOMM connection if encryption
was requested and the remote side disables encryption.
The problem occurs during Role Switch. Bluetooth 2.0 devices have to
drop encryption temporarily during the role switch, but when this
remote side does this we immediately disconnect due to this patch.
Here is an example:
2009-01-08 11:17:52.972625 > HCI Event: Encrypt Change (0x08) plen 4
status 0x00 handle 1 encrypt 0x00
2009-01-08 11:17:53.021362 < ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x009c len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 4 pf 1 ilen 0 fcs 0x77
2009-01-08 11:17:53.139648 > HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:1A:0E:7E:6B:70 role 0x01
Role: Slave
2009-01-08 11:17:53.142120 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 1 packets 1
2009-01-08 11:17:53.165161 < ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x009b scid 0x0040
2009-01-08 11:17:53.279174 > HCI Event: Encrypt Change (0x08) plen 4
status 0x00 handle 1 encrypt 0x01
(With Bluetooth 2.1 this is solved with the Encryption pause and
resume LMP command)
Reverting this patch is unfortunate because it leaves us less secure -
we continue happily even if the remote side drops encryption. In
practice this does not normally happen. However we cannot ship a HFP
product with this commit because many CSR headsets like to role
switch. This will be affecting all bluez users that use LM_ENCRYPT or
LM_SECURE with devices that role switch and maybe the best approach is
to also revert this commit in mainline.
The other alternative is to introduce a timer that starts when the
remote side drops encryption. They then have say 5 seconds to complete
a role switch and re-establish encryption, otherwise the RFCOMM link
is dropped. Any other ideas?
No. At least all the headsets that I have tested re-enables encryption
after a while. I have preliminary patch set which implements this. I'll
send it for commants to the list soon. RFCOMM TX should be halted also
while encryption is disabled.
Another problem is some 2.1 headsets which connect to non-sdp psm
without encryption. I guess they also need some hack.
--
Ville
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
