| 2017-10-03 16:32:17 |
Paolo Pisati |
description |
The physical bluetooth address is the same on all DB410cs - "00:00:00:00:5A:AD", and there's no way to change it, no matter the underlining OS (ubuntu core / classic, Debian, etc). |
Impact:
Every single dragonboard out there employs the same physical bluetooth address ("00:00:00:00:5A:AD") - that would be the problem if two boards tried to communicate with each other, and in general, having a single physical address shared among all boards is a bad idea.
Fix:
The attached patches introduce a new DTB binding ("local-bd-address") that the user can exploit to override the default address.
How to test:
First boot an unpatched kernel and check the hci0 address:
$ sudo hciconfig
hci0: Type: BR/EDR Bus: UNKNOWN
BD Address: 00:00:00:00:5A:AD ACL MTU: 0:0 SCO MTU: 0:0
UP RUNNING RAW
RX bytes:0 acl:0 sco:0 events:3 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
then install the patched kernel, reboot, stop at the uboot prompt and issue:
dragonboard410c => ext4load mmc 1:9 ${fdt_addr} /boot/apq8016-sbc.dtb
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt resize
dragonboard410c => fdt list /smd/pronto/bt
bt {
compatible = "qcom,hci-smd";
qcom,smd-channels = "APPS_RIVA_BT_CMD", "APPS_RIVA_BT_ACL";
qcom,smd-channel-names = "event", "data";
};
set the local-bd-address property to the desired new address:
dragonboard410c => fdt set /smd/pronto/bt local-bd-address [55 44 33 22 11 00]
check that the change was effectively applied:
dragonboard410c => fdt list /smd/pronto/bt
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,hci-smd";
qcom,smd-channels = "APPS_RIVA_BT_CMD", "APPS_RIVA_BT_ACL";
qcom,smd-channel-names = "event", "data";
};
and continue booting:
dragonboard410c => run loadkernel; run doboot
Once the OS is alive, check again hci0 address:
$ sudo hciconfig
hci0: Type: BR/EDR Bus: UNKNOWN
BD Address: 00:11:22:33:44:55 ACL MTU: 1024:7 SCO MTU: 50:8
UP RUNNING
RX bytes:0 acl:0 sco:0 events:45 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
NB: The booting process might change depending on the image/distribution you are using, verify your uboot environment and extrapolate the necessary steps from the above instruction. |
|
| 2017-10-03 16:33:49 |
Paolo Pisati |
description |
Impact:
Every single dragonboard out there employs the same physical bluetooth address ("00:00:00:00:5A:AD") - that would be the problem if two boards tried to communicate with each other, and in general, having a single physical address shared among all boards is a bad idea.
Fix:
The attached patches introduce a new DTB binding ("local-bd-address") that the user can exploit to override the default address.
How to test:
First boot an unpatched kernel and check the hci0 address:
$ sudo hciconfig
hci0: Type: BR/EDR Bus: UNKNOWN
BD Address: 00:00:00:00:5A:AD ACL MTU: 0:0 SCO MTU: 0:0
UP RUNNING RAW
RX bytes:0 acl:0 sco:0 events:3 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
then install the patched kernel, reboot, stop at the uboot prompt and issue:
dragonboard410c => ext4load mmc 1:9 ${fdt_addr} /boot/apq8016-sbc.dtb
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt resize
dragonboard410c => fdt list /smd/pronto/bt
bt {
compatible = "qcom,hci-smd";
qcom,smd-channels = "APPS_RIVA_BT_CMD", "APPS_RIVA_BT_ACL";
qcom,smd-channel-names = "event", "data";
};
set the local-bd-address property to the desired new address:
dragonboard410c => fdt set /smd/pronto/bt local-bd-address [55 44 33 22 11 00]
check that the change was effectively applied:
dragonboard410c => fdt list /smd/pronto/bt
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,hci-smd";
qcom,smd-channels = "APPS_RIVA_BT_CMD", "APPS_RIVA_BT_ACL";
qcom,smd-channel-names = "event", "data";
};
and continue booting:
dragonboard410c => run loadkernel; run doboot
Once the OS is alive, check again hci0 address:
$ sudo hciconfig
hci0: Type: BR/EDR Bus: UNKNOWN
BD Address: 00:11:22:33:44:55 ACL MTU: 1024:7 SCO MTU: 50:8
UP RUNNING
RX bytes:0 acl:0 sco:0 events:45 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
NB: The booting process might change depending on the image/distribution you are using, verify your uboot environment and extrapolate the necessary steps from the above instruction. |
Impact:
Every single dragonboard employs the same physical bluetooth address ("00:00:00:00:5A:AD") - that would be the problem if two boards tried to communicate with each other, and in general, having a single physical address shared among all boards is a bad idea.
Fix:
The attached patches introduce a new DTB binding ("local-bd-address") that the user can exploit to override the default address.
How to test:
First boot an unpatched kernel and check the hci0 address:
$ sudo hciconfig
hci0: Type: BR/EDR Bus: UNKNOWN
BD Address: 00:00:00:00:5A:AD ACL MTU: 0:0 SCO MTU: 0:0
UP RUNNING RAW
RX bytes:0 acl:0 sco:0 events:3 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
then install the patched kernel, reboot, stop at the uboot prompt and issue:
dragonboard410c => ext4load mmc 1:9 ${fdt_addr} /boot/apq8016-sbc.dtb
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt resize
dragonboard410c => fdt list /smd/pronto/bt
bt {
compatible = "qcom,hci-smd";
qcom,smd-channels = "APPS_RIVA_BT_CMD", "APPS_RIVA_BT_ACL";
qcom,smd-channel-names = "event", "data";
};
set the local-bd-address property to the desired new address:
dragonboard410c => fdt set /smd/pronto/bt local-bd-address [55 44 33 22 11 00]
check that the change was effectively applied:
dragonboard410c => fdt list /smd/pronto/bt
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,hci-smd";
qcom,smd-channels = "APPS_RIVA_BT_CMD", "APPS_RIVA_BT_ACL";
qcom,smd-channel-names = "event", "data";
};
and continue booting:
dragonboard410c => run loadkernel; run doboot
Once the OS is alive, check again hci0 address:
$ sudo hciconfig
hci0: Type: BR/EDR Bus: UNKNOWN
BD Address: 00:11:22:33:44:55 ACL MTU: 1024:7 SCO MTU: 50:8
UP RUNNING
RX bytes:0 acl:0 sco:0 events:45 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
NB: The booting process might change depending on the image/distribution you are using, verify your uboot environment and extrapolate the necessary steps from the above instruction. |
|
