btusb and HCI_RAW

btusb and HCI_RAW

[Matthieu CASTET]

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 ?

Re: btusb and HCI_RAW

[Marcel Holtmann]

Hi Matthieu,

> 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.

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

Re: btusb and HCI_RAW

[Matthieu CASTET]

Hi Marcel,


Marcel Holtmann a écrit :
> Hi Matthieu,
> 
>> 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.
> 
> 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.


> 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

Re: btusb and HCI_RAW

[Marcel Holtmann]

Hi Matthieu,

>>> 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.
>>
>> 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.

there is not concept of max alternate setting. You just have to use  
the right one and powertop showed the difference in power consumption.

>> 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.

> 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

Re: btusb and HCI_RAW

[Matthieu CASTET]

Hi Marcel,

Marcel Holtmann a écrit :
> Hi Matthieu,
> 
>> 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.
> 
> 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 ?

>>> 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" .

> 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