Hi guys,
I was checking the latest BlueZ source code and the kernel source code,
and I noticed that by default EDR is disabled, when a dongle is detected
net/bluetooth/hci_core.c initializes the packet types with DM1, DH1 and
HV1, and then net/bluetooth/hci_event.c does it for DM3-5 DH3-5 and
HV3-5, but it never initializes the 2DHx or 3DHx. Was it made on purpose
or is it a bug in the code?
I just figured out how to help and try fixing it, but kernel hacking
isn't an easy to do task, and would prefer to get professional advice first.
Manuel
Hi Marcel,
> Hi Manuel,
>
>> I was checking the latest BlueZ source code and the kernel source code,
>> and I noticed that by default EDR is disabled, when a dongle is detected
>> net/bluetooth/hci_core.c initializes the packet types with DM1, DH1 and
>> HV1, and then net/bluetooth/hci_event.c does it for DM3-5 DH3-5 and
>> HV3-5, but it never initializes the 2DHx or 3DHx. Was it made on purpose
>> or is it a bug in the code?
> you have read the specification and realized that EDR uses inverse
> values?
I can't find that, but still I could find that according to the 2.1
specs + EDR when you want to enable EDR is up to the master or slave to
ask for the package type switch, that means as far as I understand ask
the other side to enable 2-DH1,2-DH3,2-DH5,3-DH1,3-DH3,3-DH5.
I get from this that from the BlueZ point of view is either the kernel
that should do that, or the BlueZ daemon or just rely that to the user
application.
But I think there are a few of non covered issues here, first when you
attach an EDR dongle which has the EDR (this means is capable of doing
2mbps and 3mbps acl connections the kernel side doesn't show this to the
userland (hciconfig), I made a patch that does exactly that, during the
device recognition of the kernel just read the features provided and or
that to the pkt_type flag. This helps a lot, now my dongle shows it can
do EDR:
EDR compatible:
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 2-DH1 2-DH3
2-DH5 3-DH1 3-DH3 3-DH5
EDR not compatible:
Features: 0xff 0xff 0x8f 0xf8 0x1b 0xf8 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
If you think the patch is sane to be included then I format it properly
so far I made it against compat-wireless-2.6.36-4 but it wouldn't be an
issue to make it against the current kernel source.
Next thing was playing with hcitool cpt and that did work, I get speed
improvements, from ~ 60KBs I get up to 100KBs to the same device, just
by forcing it to only do 3-DH5 (which I know is not a good idea, because
it's best for both radios to adapt, based on the environment).
I think it's a good idea to rely EDR "enabling" to the user space,
otherwise connection complexity on the kernel well be way harder to
keep. I think the best would be to add some stuff to the DBUS so first
let the user know which packet types are available, second to allow it
to change on a new connection.
Please let me know what you think about it,
Manuel
Hi Manuel,
> I was checking the latest BlueZ source code and the kernel source code,
> and I noticed that by default EDR is disabled, when a dongle is detected
> net/bluetooth/hci_core.c initializes the packet types with DM1, DH1 and
> HV1, and then net/bluetooth/hci_event.c does it for DM3-5 DH3-5 and
> HV3-5, but it never initializes the 2DHx or 3DHx. Was it made on purpose
> or is it a bug in the code?
you have read the specification and realized that EDR uses inverse
values?
Regards
Marcel