<div><div>Hi Marcel,<br><br>> this is not a proper fix for this problem. And you only reset the local<br>> host controller. There is no way to send a reset to the remote device.<br></div><div><br>I'm pretty new to both bluetooth and HID in general, so I'm happy to take your word for it that I'm doing the wrong thing. I would dispute the claim that there is no way to send a reset to the remote device, as calling hci_reset_req causes the remote device to stop sending packets almost immediately (5 more packets arrive compared to 70 per second before). Even the lights turn off immediately.
<br><br>I don't know enough about the stack to know exactly what is going on, but certainly hci_reset_req does appear to send a reset command somewhere:<br><br> hci_send_cmd(hdev, OGF_HOST_CTL, OCF_RESET, 0, NULL);
<br><br>and it takes a hdev which as far as I can make it represents a specific connection to a remote device rather than the entire local stack.<br><br>> Did you ever used hcidump and try to find out, why the other side still
<br>> things that we are connected. Especially why the local controller things
<br>> that we are still connected.</div><div><br>Obviously, as these devices are already pumping out data before the machine boots, I've no way of tracking what if any negotiation linux might have attempted to make with them.
There's nothing interesting in the syslog before that point:<br><br>Jul 3 18:41:52 ps3 kernel: eth0: no IPv6 routers present<br>Jul 3 18:41:52 ps3 hcid[2291]: Bluetooth HCI daemon<br>Jul 3 18:41:52 ps3 kernel: Bluetooth: L2CAP ver
2.8<br>Jul 3 18:41:52 ps3 kernel: Bluetooth: L2CAP socket layer initialized<br>Jul 3 18:41:52 ps3 hcid[2291]: HCI dev 0 registered<br>Jul 3 18:41:52 ps3 hcid[2291]: Starting SDP server<br>Jul 3 18:41:52 ps3 kernel: Bluetooth: HIDP (Human Interface Emulation) ver
1.2<br>Jul 3 18:41:52 ps3 hcid[2291]: HCI dev 0 up<br>Jul 3 18:41:52 ps3 hcid[2291]: Device hci0 has been added<br>Jul 3 18:41:53 ps3 hidd[2302]: Bluetooth HID daemon<br>Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown connection handle 43 ()
<br>Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown connection handle 47 ()<br>Jul 3 18:41:53 ps3 last message repeated 3 times<br>Jul 3 18:41:53 ps3 hcid[2291]: Device hci0 has been activated
<br>Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown connection handle 43 ()<br>Jul 3 18:41:53 ps3 last message repeated 3 times<br>Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown connection handle 47 ()
<br>Jul 3 18:41:53 ps3 last message repeated 3 times<br><br>Certainly nothing in the data has changed, which is exactly the same as before the reboot (here are two devices broadcasting simultaneously):<br><br>> ACL data: handle 47 flags 0x02 dlen 54
<br> L2CAP(d): cid 0x0041 len 50 [psm 0]
<br> A1 01 00 00 00 00 00 8B 79 8C 78 00 00 00 00 00 00 00 00 00 <br> 00 00 00 00 00 00 00 00 00 00 03 03 14 FF B5 00 12 23 FA 77 <br> 01 81 02 07 01 EE 01 96 00 02 <br>> ACL data: handle 43 flags 0x02 dlen 54
<br> L2CAP(d): cid 0x0041 len 50 [psm 0]<br> A1 01 00 00 00 00 00 79 7A 77 7F 00 00 00 00 00 00 00 00 00 <br> 00 00 00 00 00 00 00 00 00 00 03 05 14 FF BA 00 0C 23 16 77 <br> 01 81 02 07 01 EF 01 94 00 02
<br>> ACL data: handle 43 flags 0x02 dlen 54<br> L2CAP(d): cid 0x0041 len 50 [psm 0]<br> A1 01 00 00 00 00 00 79 7A 77 7F 00 00 00 00 00 00 00 00 00 <br> 00 00 00 00 00 00 00 00 00 00 03 05 14 FF BA 00 0C 23 16 77
<br> 01 81 02 07 01 EF 01 93 00 02 <br><br>etc.<br><br>Additionally, because the linux subsystem hasn't connected with them at this point, there's no way of initiating a connection with them or stopping them:
<br><br>root@ps3:~# hcitool con<br>Connections:<br>root@ps3:~# hidd list<br>root@ps3:~# <br><br>> The PS3 remote controller (and the PS3 itself) have special hacked up<br>> version of Bluetooth firmware to play nice with remote wakeup. So it
<br>> might simply be an issue with them and it might be better we declare<br>> them broken instead of adding nasty crap in a clean Bluetooth core. Your
<br>> patch is nasty crap since I haven't seen any real argument why we should<br>> reset our local controller in that case. It is wild guessing.<br></div><div><br>You might be happy to declare these controllers broken, however they exist and people want to use them.
<br><br>Do you have any suggestions of an alternative approach to handling this error condition rather than just filling up the syslog? It's definitely a very real DOS possibility - my syslog was growing by about 1Mb per minute with just two regular controllers. Someone who deliberately constructed a device to bombard a linux box with junk bluetooth data could probably fill someone's /var partition in a matter of hours.
<br><br>Cheers,<br> Ralf.</div></div><br>