On 22 August 2016 at 16:27, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Jay, Marcel, > > On Mon, Aug 22, 2016 at 11:51 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: >> Hi Jay, >> >>> I have the IoT device Hexiwear[1], which connects through BLE. They >>> have an android app which can take data from it. I want to use from my >>> linux machine. Its BLE API is provided at their github[2] page. >> >> does it work on Android? If so, then enable Bluetooth HCI tracing/logging in Android and send around the /sdcard/btsnoop_hci.log file. You can read that wit btmon by yourself and compare. >> >> I would also propose you start using btmon instead of hcidump. > Hi Marcell, Luiz, I took the btsnoop log from Android while the device is being paired. To my surprise btmon crashes as I scroll down. The file is attached. The crash is probably a different discussion, but given below is the backtrace. Can you please check if the same file crashes your btmon as well? #0 0x00007ffff7a4b6f5 in raise () from /lib64/libc.so.6 #1 0x00007ffff7a4d2fa in abort () from /lib64/libc.so.6 #2 0x00007ffff7a8c670 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff7b2bc57 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007ffff7b29d80 in __chk_fail () from /lib64/libc.so.6 #5 0x00007ffff7b29339 in _IO_str_chk_overflow () from /lib64/libc.so.6 #6 0x00007ffff7a905a0 in __GI__IO_default_xsputn () from /lib64/libc.so.6 #7 0x00007ffff7a635ac in vfprintf () from /lib64/libc.so.6 #8 0x00007ffff7b293cc in __vsprintf_chk () from /lib64/libc.so.6 #9 0x00007ffff7b2931d in __sprintf_chk () from /lib64/libc.so.6 #10 0x000055555558a533 in print_uuid () #11 0x0000555555588352 in att_packet () #12 0x00005555555888f3 in l2cap_frame () #13 0x000055555557f517 in packet_hci_acldata () #14 0x000055555557fae7 in packet_monitor () #15 0x000055555556a1c6 in control_reader () #16 0x00005555555670bc in main () > The D-Bus GATT should be able to handle those, if we are able to > connect, but there seems to be something wrong with the specification > as it does seems to use UUID range reserved by the SIG instead of > using proper 128 bits UUIDs. > Since I do not know about much bluez stack, are you telling that some changes needs to be done within the bluez stack so as to connect/pair to such BLE devices which use UUIDs reserved by SIG rather than private ones? And could you please clarify about "something wrong with the specification" ? > -- > Luiz Augusto von Dentz -- Thanks and Regards, Aurabindo J
btsnoop ê