btusb and HCI_RAW
Hi,
with HCI_RAW, application can bypass the bluez stack and send raw stuff to dongle.
This seems not possible anymore with btusb because it uses "hdev->conn_hash" to check if ACLDATA/SCODATA should be send/received.
These checks make the HCI_RAW mode a bit useless (ie not working for acl and sco).
Can we make the HCI_RAW work like before with acl and sco data ? For example we can ignore theses check in HCI_RAW mode and send a notify event when we turn on/off HCI_RAW mode.
Matthieu
PS : what happen if a dongle receive acl/sco data that aren't collected by the host (because urb aren't submitted) ?
They remain in a FIFO ? There are dropped ?
Marcel Holtmann
maintainerHi Matthieu,
Quoted 6 lines
with
HCI_RAW, application can bypass the bluez stack and send raw stuff to dongle.This seems not possible anymore with btusb because it uses "
hdev->conn_hash" to check if ACLDATA/SCODATA should be send/received.
Quoted 6 lines
These checks make the
HCI_RAWmode a bit useless (ie not working for acl and sco).Can we make the
HCI_RAWwork like before with acl and sco data ? For example we can ignore theses check inHCI_RAWmode and send a notify event when we turn on/offHCI_RAWmode.
we could, but that will cost a lot of CPU power. The SCO data packets are just not an option here. Also without a full blown Bluetooth stack, you don't know with alternate setting to use. So this is a little bit pointless here and before just worked by pure luck. Why do you want this support in the first place?
Regards
Marcel
Hi Marcel,
Quoted 11 lines · Marcel Holtmann
Hi Matthieu,
Quoted 9 lines
with
HCI_RAW, application can bypass the bluez stack and send raw stuff to dongle.This seems not possible anymore with btusb because it uses "
hdev->conn_hash" to check if ACLDATA/SCODATA should be send/received.These checks make the
HCI_RAWmode a bit useless (ie not working for acl and sco).
Quoted 7 lines
Quoted 3 lines
Can we make the
HCI_RAWwork like before with acl and sco data ? For example we can ignore theses check inHCI_RAWmode and send a notify event when we turn on/offHCI_RAWmode.we could, but that will cost a lot of CPU power. The SCO data packets are just not an option here. Also without a full blown Bluetooth stack, you don't know with alternate setting to use.
But hci_usb wasn't doing that (ie always use max alternate setting + submit sco/alc urb), and I wasn't under the impression that it costs too much CPU power.
Quoted 4 lines
So this is a little bit
pointless here and before just worked by pure luck. Why do you want this support in the first place?
This can be helpful to test userspace bluetooth stack or do some fuzzing.
What is the goal of HCI_RAW ?
With btusb it seems useless in the tx path.
Matthieu
Marcel Holtmann
maintainerHi Matthieu,
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
with
HCI_RAW, application can bypass the bluez stack and send raw stuff to dongle.This seems not possible anymore with btusb because it uses "
hdev->conn_hash" to check if ACLDATA/SCODATA should be send/received.These checks make the
HCI_RAWmode a bit useless (ie not working for acl and sco).Can we make the
HCI_RAWwork like before with acl and sco data ? For example we can ignore theses check inHCI_RAWmode and send a notify event when we turn on/offHCI_RAWmode.
Quoted 6 lines
Quoted 3 lines
we could, but that will cost a lot of CPU power. The SCO data packets are just not an option here. Also without a full blown Bluetooth stack, you don't know with alternate setting to use.
But
hci_usbwasn't doing that (ie always use max alternate setting + submit sco/alc urb), and I wasn't under the impression that it costs too much CPU power.
there is not concept of max alternate setting. You just have to use the right one and powertop showed the difference in power consumption.
Quoted 5 lines
Quoted 4 lines
So this is a little bit
pointless here and before just worked by pure luck. Why do you want this support in the first place?This can be helpful to test userspace bluetooth stack or do some fuzzing.
I seriously couldn't care less about any userspace Bluetooth stack. Also why is RAW not working for ACL packets. It actually should work if the adapter is brought up properly and switched to RUNNING state. SCO will not be possible without magic.
Quoted 2 lines
What is the goal of
HCI_RAW?
With btusb it seems useless in the tx path.
It is mainly used for commands and events and for that it works perfectly fine.
Regards
Marcel
Hi Marcel,
Quoted 9 lines · Marcel Holtmann
Hi Matthieu,
Quoted 3 lines
But
hci_usbwasn't doing that (ie always use max alternate setting + submit sco/alc urb), and I wasn't under the impression that it costs too much CPU power.there is not concept of max alternate setting. You just have to use the right one and powertop showed the difference in power consumption.
Ok, but in normal case HCI_RAW isn't enabled ?
So the high power consumption only happen when you use this mode, which shouldn't happen for normal users ?
Quoted 8 lines
Quoted 5 lines
Quoted 4 lines
So this is a little bit
pointless here and before just worked by pure luck. Why do you want this support in the first place?This can be helpful to test userspace bluetooth stack or do some fuzzing.
I seriously couldn't care less about any userspace Bluetooth stack. Also why is RAW not working for ACL packets.
Do you mean HCI_RAW or l2cap raw ?
For HCI_RAW case, what will call hci_connect for ACL_LINK ? This seems need to have "hdev->conn_hash.acl_num > 0" .
Quoted 2 lines
adapter is brought up properly and switched to RUNNING state. SCO will not be possible without magic.
Also why in hci_sock_sendmsg there isn't check to return error if it is impossible to send raw sco/acl ?
Regards,
Matthieu