From: Ranulf Doswell <[email protected]>
Send a reset command to any device that sends us data when there is no
active
connection to that device. This hopefully discourages the device from
sending
any more data which causes the syslog to fill up rapidly otherwise.
Signed-off-by: Ranulf Doswell <[email protected]>
---
An example device which causes this problem is the Sony Playstation six-axis
controller which continues sending data even after the host is rebooted as
the linux kernel stack returns before the controller's stack times out.
This patch is against 2.6.22-rc5
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8943c93..fb99b95 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1340,6 +1340,12 @@ static inline void hci_acldata_packet(struct hci_dev
*hdev, struct sk_buff *skb)
} else {
BT_ERR("%s ACL packet for unknown connection handle %d",
hdev->name, handle);
+
+ /* Force the device to reset in the hope that it will then
+ * leave us alone. In some devices, a reboot doesn't provide
+ * enough time for the device's stack to time out, so it
keeps
+ * sending data until forcibly terminated. */
+ hci_reset_req(hdev, 0);
}
kfree_skb(skb);
Hi Geert,
> > 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.
>
> Perhaps you can replace the call to printk() with a call to printk_ratelimit()?
we could. Feel free to send a patch for it.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hello again
> > I'm pretty new to both bluetooth and HID in general, [...]
> That you don't see no packets on HCI doesn't mean that no packets are
> sent from the remote device anymore.
That appears to be a critical point I haven't yet figured out.
I've been trying to understand the minimum of bluetooth stack, HCI, USB,
HID, protocol descriptors, etc to try to figure out how to get the blu-ray
remote working (another issue) but I'm still getting my head around how all
the bits fit together as, for instance, it took a while to figure out how
the PS3 controller seemed to "just work"... :)
This was just a problem I discovered along the way, which seemed to have a
simple fix. If it's wrong, I'm happy to leave it to someone who knows
better! Geoff knows about the issue now, so I guess when he revisits the
bluetooth stuff, he might find a better solution to the problem.
> And there is no way to send a reset to a remote device. Period.
I'd like to figure out what's going on though, as the lights stop flashing
on the device when we do this local reset. Maybe it changes some lower level
state so packets are NAK'd instead, but I'd like to understand that process
in that case.
> > 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:
> That makes no sense. The HID devices can re-connect. However they have
> to indicate this via requesting a ACL connection. Otherwise we can't
> know what to do with the data packets.
My understanding is that the controller believes it is already connected and
so it never tries to reconnect and instead just keeps sending data.
Maybe a reconnection does occur at some layer below ACL that I don't
understand yet, but I thought ACL was the lowest layer, so I've not been
looking for that.
>It is not a DoS, because you have to connect it first. And obviously you
> told your PS3 remote controller to user your system.
Looking back at the logs, I see that the messages do start around the time
hcid is loaded (which is set to autoconnect without authentication), so
maybe it has actually established a channel by that point.
There's nothing in the logs about a connection and hcitool doesn't list
anything, but I've not enough experience with other devices to know what's
actually going on.
Thanks for your input - I suspect I've got a lot of learning about bluetooth
to come...
Cheers,
Ralf.
Hi Ranulf,
>
> > this is not a proper fix for this problem. And you only reset the
> local
> > host controller. There is no way to send a reset to the remote
> device.
>
>
> 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.
no. You reset the local controller and it will tear down every piconet.
That you don't see no packets on HCI doesn't mean that no packets are
sent from the remote device anymore. And there is no way to send a reset
to a remote device. Period.
> 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:
>
> hci_send_cmd(hdev, OGF_HOST_CTL, OCF_RESET, 0, NULL);
>
> 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.
No. The hdev only represents a local device.
> > Did you ever used hcidump and try to find out, why the other side
> still
> > things that we are connected. Especially why the local controller
> things
> > that we are still connected.
>
> 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:
>
> Jul 3 18:41:52 ps3 kernel: eth0: no IPv6 routers present
> Jul 3 18:41:52 ps3 hcid[2291]: Bluetooth HCI daemon
> Jul 3 18:41:52 ps3 kernel: Bluetooth: L2CAP ver 2.8
> Jul 3 18:41:52 ps3 kernel: Bluetooth: L2CAP socket layer initialized
> Jul 3 18:41:52 ps3 hcid[2291]: HCI dev 0 registered
> Jul 3 18:41:52 ps3 hcid[2291]: Starting SDP server
> Jul 3 18:41:52 ps3 kernel: Bluetooth: HIDP (Human Interface
> Emulation) ver 1.2
> Jul 3 18:41:52 ps3 hcid[2291]: HCI dev 0 up
> Jul 3 18:41:52 ps3 hcid[2291]: Device hci0 has been added
> Jul 3 18:41:53 ps3 hidd[2302]: Bluetooth HID daemon
> Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for
> unknown connection handle 43 ()
> Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for
> unknown connection handle 47 ()
> Jul 3 18:41:53 ps3 last message repeated 3 times
> Jul 3 18:41:53 ps3 hcid[2291]: Device hci0 has been activated
> Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for
> unknown connection handle 43 ()
> Jul 3 18:41:53 ps3 last message repeated 3 times
> Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for
> unknown connection handle 47 ()
> Jul 3 18:41:53 ps3 last message repeated 3 times
>
> Certainly nothing in the data has changed, which is exactly the same
> as before the reboot (here are two devices broadcasting
> simultaneously):
>
> > ACL data: handle 47 flags 0x02 dlen 54
> L2CAP(d): cid 0x0041 len 50 [psm 0]
> A1 01 00 00 00 00 00 8B 79 8C 78 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 03 03 14 FF B5 00 12 23 FA 77
> 01 81 02 07 01 EE 01 96 00 02
> > ACL data: handle 43 flags 0x02 dlen 54
> L2CAP(d): cid 0x0041 len 50 [psm 0]
> A1 01 00 00 00 00 00 79 7A 77 7F 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 03 05 14 FF BA 00 0C 23 16 77
> 01 81 02 07 01 EF 01 94 00 02
> > ACL data: handle 43 flags 0x02 dlen 54
> L2CAP(d): cid 0x0041 len 50 [psm 0]
> A1 01 00 00 00 00 00 79 7A 77 7F 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 03 05 14 FF BA 00 0C 23 16 77
> 01 81 02 07 01 EF 01 93 00 02
>
> etc.
>
> 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:
That makes no sense. The HID devices can re-connect. However they have
to indicate this via requesting a ACL connection. Otherwise we can't
know what to do with the data packets.
> > The PS3 remote controller (and the PS3 itself) have special hacked
> up
> > version of Bluetooth firmware to play nice with remote wakeup. So
> it
> > might simply be an issue with them and it might be better we declare
> > them broken instead of adding nasty crap in a clean Bluetooth core.
> Your
> > patch is nasty crap since I haven't seen any real argument why we
> should
> > reset our local controller in that case. It is wild guessing.
>
>
> You might be happy to declare these controllers broken, however they
> exist and people want to use them.
>
> 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.
It is not a DoS, because you have to connect it first. And obviously you
told your PS3 remote controller to user your system.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> this is not a proper fix for this problem. And you only reset the local
> host controller. There is no way to send a reset to the remote device.
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.
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:
hci_send_cmd(hdev, OGF_HOST_CTL, OCF_RESET, 0, NULL);
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.
> Did you ever used hcidump and try to find out, why the other side still
> things that we are connected. Especially why the local controller things
> that we are still connected.
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:
Jul 3 18:41:52 ps3 kernel: eth0: no IPv6 routers present
Jul 3 18:41:52 ps3 hcid[2291]: Bluetooth HCI daemon
Jul 3 18:41:52 ps3 kernel: Bluetooth: L2CAP ver 2.8
Jul 3 18:41:52 ps3 kernel: Bluetooth: L2CAP socket layer initialized
Jul 3 18:41:52 ps3 hcid[2291]: HCI dev 0 registered
Jul 3 18:41:52 ps3 hcid[2291]: Starting SDP server
Jul 3 18:41:52 ps3 kernel: Bluetooth: HIDP (Human Interface Emulation) ver
1.2
Jul 3 18:41:52 ps3 hcid[2291]: HCI dev 0 up
Jul 3 18:41:52 ps3 hcid[2291]: Device hci0 has been added
Jul 3 18:41:53 ps3 hidd[2302]: Bluetooth HID daemon
Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown
connection handle 43 ()
Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown
connection handle 47 ()
Jul 3 18:41:53 ps3 last message repeated 3 times
Jul 3 18:41:53 ps3 hcid[2291]: Device hci0 has been activated
Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown
connection handle 43 ()
Jul 3 18:41:53 ps3 last message repeated 3 times
Jul 3 18:41:53 ps3 kernel: hci_acldata_packet: hci0 ACL packet for unknown
connection handle 47 ()
Jul 3 18:41:53 ps3 last message repeated 3 times
Certainly nothing in the data has changed, which is exactly the same as
before the reboot (here are two devices broadcasting simultaneously):
> ACL data: handle 47 flags 0x02 dlen 54
L2CAP(d): cid 0x0041 len 50 [psm 0]
A1 01 00 00 00 00 00 8B 79 8C 78 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 03 03 14 FF B5 00 12 23 FA 77
01 81 02 07 01 EE 01 96 00 02
> ACL data: handle 43 flags 0x02 dlen 54
L2CAP(d): cid 0x0041 len 50 [psm 0]
A1 01 00 00 00 00 00 79 7A 77 7F 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 03 05 14 FF BA 00 0C 23 16 77
01 81 02 07 01 EF 01 94 00 02
> ACL data: handle 43 flags 0x02 dlen 54
L2CAP(d): cid 0x0041 len 50 [psm 0]
A1 01 00 00 00 00 00 79 7A 77 7F 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 03 05 14 FF BA 00 0C 23 16 77
01 81 02 07 01 EF 01 93 00 02
etc.
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:
root@ps3:~# hcitool con
Connections:
root@ps3:~# hidd list
root@ps3:~#
> The PS3 remote controller (and the PS3 itself) have special hacked up
> version of Bluetooth firmware to play nice with remote wakeup. So it
> might simply be an issue with them and it might be better we declare
> them broken instead of adding nasty crap in a clean Bluetooth core. Your
> patch is nasty crap since I haven't seen any real argument why we should
> reset our local controller in that case. It is wild guessing.
You might be happy to declare these controllers broken, however they exist
and people want to use them.
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.
Cheers,
Ralf.
Marcel Holtmann wrote:
> Hi Ranulf,
>
>> Send a reset command to any device that sends us data when there is no
>> active
>> connection to that device. This hopefully discourages the device from
>> sending
>> any more data which causes the syslog to fill up rapidly otherwise.
>>
>> Signed-off-by: Ranulf Doswell <[email protected]>
>>
>> ---
>>
>> An example device which causes this problem is the Sony Playstation
>> six-axis
>> controller which continues sending data even after the host is
>> rebooted as
>> the linux kernel stack returns before the controller's stack times
>> out.
>
> this is not a proper fix for this problem. And you only reset the local
> host controller. There is no way to send a reset to the remote device.
>
> Did you ever used hcidump and try to find out, why the other side still
> things that we are connected. Especially why the local controller things
> that we are still connected.
>
> The PS3 remote controller (and the PS3 itself) have special hacked up
> version of Bluetooth firmware to play nice with remote wakeup. So it
> might simply be an issue with them and it might be better we declare
> them broken instead of adding nasty crap in a clean Bluetooth core. Your
> patch is nasty crap since I haven't seen any real argument why we should
> reset our local controller in that case. It is wild guessing.
I'll look at this in more detail when I have some time, maybe in a month or so.
-Geoff
Hi Ranulf,
> Send a reset command to any device that sends us data when there is no
> active
> connection to that device. This hopefully discourages the device from
> sending
> any more data which causes the syslog to fill up rapidly otherwise.
>
> Signed-off-by: Ranulf Doswell <[email protected]>
>
> ---
>
> An example device which causes this problem is the Sony Playstation
> six-axis
> controller which continues sending data even after the host is
> rebooted as
> the linux kernel stack returns before the controller's stack times
> out.
this is not a proper fix for this problem. And you only reset the local
host controller. There is no way to send a reset to the remote device.
Did you ever used hcidump and try to find out, why the other side still
things that we are connected. Especially why the local controller things
that we are still connected.
The PS3 remote controller (and the PS3 itself) have special hacked up
version of Bluetooth firmware to play nice with remote wakeup. So it
might simply be an issue with them and it might be better we declare
them broken instead of adding nasty crap in a clean Bluetooth core. Your
patch is nasty crap since I haven't seen any real argument why we should
reset our local controller in that case. It is wild guessing.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel