I have trialed to use Network, NAP profiles on Bluetooth.
On Host, xUbuntu 13.04 I have followed as here.
This Host or XUbuntu machine is behind proxy & runs on virtual machine.
It is installed with Bluetooth version 4.101
On embedded board, ping 173.194.112.211 responds as below:
PING 173.194.112.211 (173.194.112.211) 56(84) bytes of data.
64 bytes from 173.194.112.211: icmp_req=1 ttl=46 time=336 ms
On embedded board, ifconfig shows as below:
bnep0 Link encap:Ethernet HWaddr 3E:DA:FB:6C:EE:BC
inet addr:10.220.129.178 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::3cda:fbff:fe6c:eebc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:1793 (1.7 KiB) TX bytes:36870 (36.0 KiB)
eth0 Link encap:Ethernet HWaddr 0C:23:C0:80:C0:E8
inet addr:10.122.83.127 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::e23:c0ff:fe80:c0e8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24555 errors:0 dropped:611 overruns:0 frame:0
TX packets:20647 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3374125 (3.2 MiB) TX bytes:5878612 (5.6 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:25809 errors:0 dropped:0 overruns:0 frame:0
TX packets:25809 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3824780 (3.6 MiB) TX bytes:3824780 (3.6 MiB)
polo0 Link encap:Ethernet HWaddr 02:00:00:00:00:01
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::ff:fe00:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:696 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:117357 (114.6 KiB)
On embedded board, I issue command: ping -I bnep0 173.194.112.211
This is google IP address by the way :)
After long time, I press Ctrl + c, it gives this:
PING 173.194.112.211 (173.194.112.211): 56 data bytes
^C
--- 173.194.112.211 ping statistics ---
541 packets transmitted, 0 packets received, 100% packet loss
On embedded board, I also trialed changing bnep0 inet addr to: 10.122.83.128.
For sure no one has this IP address.
It did not work...
hcidump -X shows these packets when I ping, not other times.
HCI sniffer - Bluetooth packet analyzer ver 2.4
device: hci0 snap_len: 1028 filter: 0xffffffff
> ACL data: handle 38 flags 0x02 dlen 47
L2CAP(d): cid 0x0042 len 43 [psm 0]
0000: 00 ff ff ff ff ff ff 3e da fb 6c ee bc 08 06 00 .......>..l.....
0010: 01 08 00 06 04 00 01 3e da fb 6c ee bc 0a dc 81 .......>..l.....
0020: b2 00 00 00 00 00 00 ad c2 70 d3 .........p.
> ACL data: handle 38 flags 0x02 dlen 47
L2CAP(d): cid 0x0042 len 43 [psm 0]
0000: 00 ff ff ff ff ff ff 3e da fb 6c ee bc 08 06 00 .......>..l.....
0010: 01 08 00 06 04 00 01 3e da fb 6c ee bc 0a dc 81 .......>..l.....
0020: b2 00 00 00 00 00 00 ad c2 70 d3 .........p.
> ACL data: handle 38 flags 0x02 dlen 47
L2CAP(d): cid 0x0042 len 43 [psm 0]
0000: 00 ff ff ff ff ff ff 3e da fb 6c ee bc 08 06 00 .......>..l.....
0010: 01 08 00 06 04 00 01 3e da fb 6c ee bc 0a dc 81 .......>..l.....
0020: b2 00 00 00 00 00 00 ad c2 70 d3 .........p.
I wish to access internet On embedded board, over Bluetooth, via xUbuntu's Ethernet's internet connection, NOT Ethernet of embedded board.
Someone please help me to get this working.
I configured bnep0 network interface on xUbuntu 13.04 with local IP address and it workded :)
# ifconfig bnep0 192.168.1.3 up
I also guess that command route also helped.
The ping works, however, there is packet loss...
Related
I'm running bluez 5.50 on a Raspberry Pi (both Buster and Stretch). I have a ble sensor device that advertises data only when a button on the sensor device is pressed. So advertisements are asynchronous and there are no periodic advertisements in between (and all packets are unique, no duplicates). I'm having an issue with Bluez though where once a packet is received, Bluez seems to not report any additional packets from the device for the next approximately 11 seconds (very occasionally the interval is shorter). This is with the bluetoothctl line command tool as well as my own c++ application (based off the bluez client/main.c example). In both cases before starting a scan I clear the scan filter, set transport to le, and set duplicate-data reporting on. Conversely, when running hcitool scan I see all the packets from the sensor (it even seems to be reporting all 3 copies broadcast on the different advertisement channels). So my question is, is there a way to get those missing advertisements through the dbus api, possibly some additional setting somewhere? If not, is the hci api okay to use from c++ and should it do the trick? Any help appreciated, thanks!
Edited per Alex's questions -
Have you tried downloading the latest bluez (5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git ?
Not yet, just wanted to check and see if this might be something known beforehand.
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
hcitool lescan (under root), and yes, the hardware is a Pi Zero/W and a P3 so BLE 4.x controllers (I assume)
Have you tried running sudo btmon to see all of the HCI communication during scanning?
I have but can't remember exactly what I saw other than it didn't contradict anything else, i.e. missing packets w/ dbus api vs hci
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
always exactly as you've noted...
Could you also provide the results of hciconfig -a
--- Results (P Zero) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:79:2E:3F ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:55476 acl:126 sco:0 events:2012 errors:0
TX bytes:6956 acl:114 sco:0 commands:444 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi01'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
--- Results (P3) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:2B:A2:A3 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:10995 acl:0 sco:0 events:390 errors:0
TX bytes:2145 acl:0 sco:0 commands:91 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi02'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
Below is a scan covering about 20 seconds (editing out all unrelated packets),
where I'm pressing down the button on the sensor about every 2 seconds and then
holding it down for another 2 seconds before letting it up. The first chunk
is from bluetoothctl, the second from "hcidump --raw" (on a second raspberry pi). The first four bytes
in the bluetoothctl packet data is a little endian packet seq number
incremented by the sensor for each new packet. The next byte indicates a
button up/down action. You can see bluetoothctl reported packets numbered 05df,
05e5, 05e9. In the raw dump the seq number is at the end of the top line. There
you can see all packets are in order, reported 1 to 3 times (I assume it is
reporting all advertising channels it catches). All packets are present 05df to
05e9 in the hcidump scan. Lastly is the output from "hcitool lescan --duplicates",
which I'm not really sure how it maps...
------ bluetoothctl
.
[NEW] Device E2:15:00:01:73:96 E2-15-00-01-73-96
[CHG] Device E2:15:00:01:73:96 RSSI: -46
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
df 05 00 00 10 a1 ac 8a b4 .........
[CHG] Device E2:15:00:01:73:96 RSSI: -45
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e5 05 00 00 10 e7 4f 67 6e ......Ogn
.
[CHG] Device E2:15:00:01:73:96 RSSI: -65
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e9 05 00 00 10 f4 f9 f8 7d ........}
---------- hcidump --raw
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 C3
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E0 05
00 00 11 11 0F 3E 24 B6
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 CF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A BF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A B8
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E3 05
00 00 10 E2 29 C7 F7 BB
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E5 05
00 00 10 E7 4F 67 6E CA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E7 05
00 00 10 2D 52 48 C2 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E9 05
00 00 10 F4 F9 F8 7D BC
------- hcitool lescan --duplicates
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
Have you tried downloading the latest bluez (5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git ?
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
Have you tried running sudo btmon to see all of the HCI communication during scanning?
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
Could you also provide the results of hciconfig -a
Handling of duplicate advertising data with the BlueZ D-Bus API is an on-going saga that is complicated by the fact that both the kernel and user-space are involved. The following thread over on the BlueZ developer mailing list probably gives the best insight: https://marc.info/?l=linux-bluetooth&m=158225950522806&w=2
The workaround I have been using with the D-Bus API, when scanning for beacons, is to remove the device once I have the data from it. I don't appear to miss data this way. As I don't connect to the beacons, I don't need to worry about losing the paring data for that device.
As a side note, tools like hciconfig, hcitool, and hcidump were deprecated back in 2017
I tried to follow the steps provided by davidgyoung in this question. Here are the commands I use:
hciconfig hci0 up
hciconfig hci0 noleadv
hcitool -i hci0 cmd 0x08 0x0008 48 45 4c 4c 4f 57 4f 52 4c 44
hciconfig hci0 leadv
Which gives me this output:
LE set advertise enable on hci0 returned status 12
< HCI Command: ogf 0x08, ocf 0x0008, plen 10
48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
Note that I can't use the advised command hciconfig hci0 leadv 0 because it will throw the error Warning: unknown command - "0".
However, when I try to read out (e.g. with a hcidump --raw) the payload in the advertised package from another device I'm getting an output like this:
hcitool lescan -- duplicates output snippet (both entries are repeated over and over again, looking at the MAC it should be the same device, though):
00:1A:7D:DA:71:14 mint17-0
00:1A:7D:DA:71:14 (unknown)
matching hcidump --raw output snippet:
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74 31 37 2D 30 BE
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08 AD
I'm using Bluez 5.26 and CSR4.0 dongles.
This is the hciconfig output of the advertisier:
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:14 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1242 acl:0 sco:0 events:77 errors:0
TX bytes:2079 acl:0 sco:0 commands:77 errors:0
And this is the hciconfig output from the 'scanner':
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:11753 acl:0 sco:0 events:552 errors:0
TX bytes:1842 acl:0 sco:0 commands:75 errors:0
What did I miss to get it to work?
Update:
Following David's advice I changed the cmd values to
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
getting this output
< HCI Command: ogf 0x08, ocf 0x0008, plen 18
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
but still gibberish payloads (payload portion of the hcidump --raw output)
af:08:0a:02:02:01:02
b7:08:0a:02:02:01:02
be:08:0a:02:02:01:02
...
Update 2:
Following the next advice I tried adding some 00 to the payload:
< HCI Command: ogf 0x08, ocf 0x0008, plen 42
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
> HCI Event: 0x0e plen 4
01 08 20 12
And here the hcidump --raw output
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AC
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
BF
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AD
So still no joy.
Would it make sense to try a different (maybe older) version of bluez? Or can it be hardware related and I should try to get different Bluetooth dongles?
Update 3:
Tried the same with bluez 5.21 which works for David.
Here's a snippet of the hcidump --raw output
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D7
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D4
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D4
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D2
The hostname has changed (tested on the third machine so far), so the output is a bit different but I still don't see 'hello world' anywhere.
At this point any ideas are more than welcome!
Update 4:
Tried a different hardware dongle (IOGEAR GBU521W6 as suggested by David) and this looks very promising now!
When using this advertising config:
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
I get this hcidump --raw output:
> 04 3E 1C 02 01 00 00 BA D0 63 70 F3 5C 10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C B5
As you can see the payload is almost complete, but the last char is missing. By changing the length attribute to 11 I get the full payload:
hcitool -i hci0 cmd 0x08 0x0008 11 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
----
> 04 3E 1D 02 01 00 00 BA D0 63 70 F3 5C 11 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 AB
So for the future (and different payloads): the required length seems to be the bytes of the payload (without the length attribute) - 17 in this case.
Important: It does not work with bluez 5.26 for me, I'm using bluez 5.21 now.
Two issues:
First, in order to get BlueZ to advertise, the byte sequence you supply must include a valid BLE advertisement header, which is a minimum of 8 bytes. So to advertise "helloworld" you actually need to send:
sudo hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
The first 8 bytes are the header and the next 10 bytes are the string "helloworld" encoded as 8-bit ASCII.
The first 8 bytes can be broken down like this:
10 # Total length of the advertising packet
02 # Number of bytes that follow in first AD structure
01 # Flags AD type
1A # Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
0C # Number of bytes that follow in second (and last) AD structure
FF # Manufacturer specific data AD type
18 01 # Company identifier code (0x0118 == Radius Networks)
Note that this header contains two different length fields that you must adjust if you change the length of the "helloworld" payload. Also, for experimentation purposes, you are welcome to use any two bytes for the company identifier that you want.
Second, you can't see the raw bytes of a detected advertisement with the hcitool lescan command. To see the raw bytes, you have to use this command in combination with the hcidump command. See here for details: https://stackoverflow.com/a/21790504/1461050
I have followed the instructions I have found on the internet for configuring the bluetooth 4 dongle with a Raspberry Pi. I thought it was going ok. Running 'hcitool dev'' shows me the device.
So I then created and ran a script:
#!/bin/bash
sudo hciconfig hci0 up
sudo hciconfig hci0 noleadv
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e5 9f fc b0 b5 2d 11 e3 a5 e2 08 00 20 0c 9a 66 00 00 00 00 c5 00
sudo hciconfig hci0 leadv 3
Running the above script gave the output:
LE set advertise enable on hci returned status 12
< HCI Command: ogf 0x08, ocf 0x0008, plen 32
1E 02 01 1A 1A FF 4C 00 02 15 E5 9F FC B0 B5 2D 11 E3 A5 E2
08 00 20 0C 9A 66 00 00 00 00 C5 00
> HCI Event: 0x0e plen 4
01 08 20 00
I don't know if the above output indicates success or failure, but I suspect all is not well because I installed Locate iB app from Radius Networks on my iPad and added in the details above for my iBeacon and the app cannot see it.
The details of the iBeacon I entered in the app are:
Proximity UUID = e59ffcb0-b52d-11e3-a5e2-0800200c9a66
Major = 0
Minor = 0
Power = -59
Any help greatly appreciated.
Paul
I recently was trying to configure ibeacon on a BLE dongle (cambridge silicon radio) on a raspberry pi.
Reference: http://developer.radiusnetworks.com/2013/10/09/how-to-make-an-ibeacon-out-of-a-raspberry-pi.html
I get this message :
HCI Command: ogf 0x08, ocf 0x0008, plen 44
1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60
D0 F5 A7 10 96 E0 00 00 00 00 C9 00 00 00 00 00 00 00 00 00
00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 12
And the app does not even locate the beacon. Though I can see the dongle flashing some light on this command:
sudo hciconfig hci0 leadv 0
But nothing gets detected.
So go an APP named LIGHTBLUE from the appstore and it detects the bluetooth with a different UUID.
I have tried this a number of times now. And have completed all the steps in the tutorial. But this bluetooth device just wont show up.
Also, I am curious to know what is 0x08 and 0x0008
and if I want to cast a different UUID what should I do? But thats a later part...
Right now, THE BLUETOOTH wont cast the Estimote UUID as said by Radius Networks' tutorial.
Hope to receive some reply soon.
Command I wrote (after this not working I changed the power to C9):
$ sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
and surprisingly, the error is: Error: Invalid HCI Command Parameters;
How come its invalid?
Is it because CSR supports 128bit rather than 64bit hex?
Thanks!
I saw the same issue as memoryhole where I had to remove the extra zeros.
I also had to enable advertising before I configured the advertising data for it to work properly with my dongle.
Here is the exact sequence/commands that worked for me:
sudo hciconfig hci0 up
sudo hciconfig hci0 leadv 3
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00
This is what my version of the Radius script ended up looking like:
#!/bin/sh
. ./ibeacon.conf
echo "Launching virtual iBeacon..."
sudo hciconfig $BLUETOOTH_DEVICE up
sudo hciconfig $BLUETOOTH_DEVICE leadv 3
sudo hcitool -i $BLUETOOTH_DEVICE cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 $UUID $MAJOR $MINOR $POWER 00
echo "Complete"
This was on a Rasberry Pi with a ORICO BTA-402-BK branded BLE dongle (CSR8510 A10)
(I would have left this as a comment, but didn't have enough rep)
I also have a CSR based USB Dongle bought in Hong Kong. I got the LE Set Advertising Data command to work by removing the extra padding at the end. According to the Bluetooth 4.0 Specification the data field should be 31 octets long. I'm not sure why the Radius Networks tutorial adds the extra zeroes. Try this:
$ sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00
Note: I didn't run this on a Raspberry Pi, but an Ubuntu 12.04 laptop with bluez-4.98.
I bought a few of these from amazon:
http://www.amazon.de/CSL-Bluetooth-Adapter-Technologie-neuester-Standard/dp/B00C68IQ3C
and did not get it to work in the beginning following the Radius tut. Running hcidump in another window showed an error message when giving the hcitool command:
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Data (0x08|0x0008) ncmd 1
status 0x12
Error: Invalid HCI Command Parameters
After removing the extra 00's at the end of the hcitool command, it worked. My config file is:
export BLUETOOTH_DEVICE=hci0
# E2C56DB5-DFFB-48D2-B060-D0F5A71096E0
# export UUID="e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0"
export UUID="92 77 83 0A B2 EB 49 0F A1 DD 7F E3 8C 49 2E DE"
export MAJOR="00 00"
export MINOR="00 00"
export POWER="C5 00"
note the extra 00 in POWER! this extra 00 is important.
My beaconstart script is:
#!/bin/sh
. ./ibeacon.conf
echo "Launching virtual iBeacon..."
sudo hciconfig $BLUETOOTH_DEVICE up
sudo hciconfig $BLUETOOTH_DEVICE noleadv
sudo hciconfig hci0 noscan
sudo hciconfig $BLUETOOTH_DEVICE leadv 3
sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 $UUID $MAJOR $MINOR $POWER
# sudo hciconfig $BLUETOOTH_DEVICE leadv 3
echo "Complete"
While try-and-erroring I also added the noscan and put the leadv 3 in FRONT of the hcitool command. But only after removing the extra 00s it started to work.
HCI Event: 0x0e plen 4 01 08 20 12
translate into: set advertising data command has finished running with error 0x12 "Invalid HCI Command Parameters"
ogf 0x08, ocf 0x0008 is the command to set the advertising packet's data, so you change the arguments to that command to modify the UUID. You want to change the part of the string of hex that corresponds to the UUID. Notice this:
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15
e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
iBeacon broadcasting Profile UUID
E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 with a major of 0 and a minor of 0
Are you sure you have a Bluetooth 4.0 dongle? What's the exact command you typed in? (cut-n-copy it into your question)
Unfortunately, you need a different bluetooth dongle. There have been other reports of the CSR not working with the Bluez stack on the Raspberry Pi for iBeacon advertising. See here and here
I have verified the command you have above does not give an error when using the recommended IOGear GBU521.
I was successful with a Raspberry Pi and a Inateck csr4b5 BT Dongle which should contain CRS 8510. By complying to the BT specs 31 octets length just like memoryhole said and omitting the extra 00 octets at the end it worked.
Edit: Also worked with a Pearl Dongle Model PX-1632-675 and a CSL USB Bluetooth Nano Dongle CSL-Nr. 23996
Give it a try.
Cheers
If I ping from the device to my PC, I am able to get tcpdump packet and see the echo go back however the packet is dropped as shown below:
eth0 Link encap:Ethernet HWaddr 00:0D:A7:00:0E:5C
inet addr:10.0.3.150 Bcast:10.0.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18714 errors:0 dropped:16850 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1380531 (1.3 MiB) TX bytes:42 (42.0 B)
Interrupt:194
This fault was found using the following setup with the below config:
CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
Linux version 3.4.52
mach-mx21ads config:
static struct smsc911x_platform_config smsc911x_config = {
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
.irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL,
.flags = SMSC911X_USE_16BIT,
};
static struct resource smsc911x_resources[] = {
{
.start = MX21_CS1_BASE_ADDR,
.end = MX21_CS1_BASE_ADDR + MX21ADS_SMSC911X_MMIO_SIZE - 1,
.flags = IORESOURCE_MEM,
}, {
.start = MX21ADS_SMSC911X_IRQ,
.end = MX21ADS_SMSC911X_IRQ,
.flags = IORESOURCE_IRQ | IRQF_TRIGGER_FALLING,
},
};
static struct platform_device smsc911x_device = {
.name = "smsc911x",
.id = -1,
.num_resources = ARRAY_SIZE(smsc911x_resources),
.resource = smsc911x_resources,
.dev = {
.platform_data = &smsc911x_config,
},
};
Linux kernel log:
[ 1.717445] 0x000001400000-0x000004000000 : "system"
[ 1.745103] smsc911x: Driver version 2008-10-21
[ 1.760910] smsc911x supply vdd33a not found, using dummy regulator
[ 1.780099] smsc911x supply vddvario not found, using dummy regulator
[ 1.799922] smsc911x smsc911x: (unregistered net_device): Driver Parameters:
[ 1.821212] smsc911x smsc911x: (unregistered net_device): LAN base: 0xC8000000
[ 1.842989] smsc911x smsc911x: (unregistered net_device): IRQ: 194
[ 1.861629] smsc911x smsc911x: (unregistered net_device): PHY will be autodetected.
[ 1.884711] smsc911x smsc911x: (unregistered net_device): BYTE_TEST: 0x87654321
[ 1.906753] smsc911x smsc911x: (unregistered net_device): LAN911x identified, idrev: 0x01150002, generation: 2
[ 1.939477] smsc911x smsc911x: eth0: Network interface: "eth0"
[ 1.957323] smsc911x smsc911x: eth0: HW_CFG EXT_PHY_DET clear, using internal PHY
[ 1.982196] smsc911x-mdio: probed
[ 1.992494] smsc911x smsc911x: eth0: PHY: addr 1, phy_id 0x0007C0D1
[ 2.011538] smsc911x smsc911x: eth0: attached PHY driver [SMSC LAN911x Internal PHY] (mii_bus:phy_addr=smsc911x-fffffff:01, irq=-1)
[ 2.047536] smsc911x smsc911x: eth0: Successfully verified loopback packet
[ 2.068587] smsc911x smsc911x: eth0: Passed Loop Back Test
[ 2.085167] smsc911x smsc911x: eth0: phy initialised successfully
[ 2.103647] smsc911x smsc911x: eth0: MAC Address is set to random_ether_addr
[ 2.124918] smsc911x smsc911x: eth0: MAC Address: 9e:04:cb:db:dc:fe
~ # /apps/bin/networking
[ 33.052642] smsc911x smsc911x: eth0: MAC Address: 00:0d:a7:00:0e:5c
[ 33.077692] smsc911x smsc911x: eth0: irq polarity: active low
[ 33.095092] smsc911x smsc911x: eth0: irq type: push-pull
[ 33.111148] smsc911x smsc911x: eth0: Testing irq handler using IRQ 194
[ 33.130867] smsc911x smsc911x: eth0: IRQ handler passed test using IRQ 194
[ 33.151606] smsc911x smsc911x: eth0: SMSC911x/921x identified at 0xc8000000, IRQ: 194
[ 33.175253] smsc911x smsc911x: eth0: maccr 0x1000000C, HASHH 0x00000000, HASHL 0x00000000
[ 33.199962] smsc911x smsc911x: eth0: maccr 0x1000000C, HASHH 0x00000000, HASHL 0x00000000
[ 33.224807] smsc911x smsc911x: eth0: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000
CONFIGURING NETWORK SETTINGS
10.0.3.150
0.0.0.0
255.255.255.0
[ 33.343312] smsc911x smsc911x: eth0: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000
[ 33.373718] smsc911x smsc911x: eth0: Interface stopped
[ 33.396198] smsc911x smsc911x: eth0: irq polarity: active low
[ 33.413592] smsc911x smsc911x: eth0: irq type: push-pull
[ 33.429650] smsc911x smsc911x: eth0: Testing irq handler using IRQ 194
[ 33.449370] smsc911x smsc911x: eth0: IRQ handler passed test using IRQ 194
[ 33.470110] smsc911x smsc911x: eth0: SMSC911x/921x identified at 0xc8000000, IRQ: 194
[ 33.493756] smsc911x smsc911x: eth0: maccr 0x1000000C, HASHH 0x00000000, HASHL 0x00000000
[ 33.518448] smsc911x smsc911x: eth0: maccr 0x1000000C, HASHH 0x00000000, HASHL 0x00000000
[ 33.543214] smsc911x smsc911x: eth0: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000
[ 33.569623] smsc911x smsc911x: eth0: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000
route: SIOCADDRT: Invalid argument
~ #
~ # [ 46.005715] smsc911x smsc911x: eth0: duplex state has changed
[ 46.023086] smsc911x smsc911x: eth0: configuring for full duplex mode
[ 46.042614] smsc911x smsc911x: eth0: rx pause disabled, tx pause disabled
[ 46.063096] smsc911x smsc911x: eth0: carrier state has changed
[ 46.080696] smsc911x smsc911x: eth0: configuring for no carrier
[ 47.095737] smsc911x smsc911x: eth0: carrier state has changed
[ 47.113360] smsc911x smsc911x: eth0: configuring for carrier OK
~ # ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Current message level: 0x0000ffff (65535)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol 0x8000
Link detected: yes
I have captured the packets being dropped. When netif_receive returns 1 the packets is dropped.
[ 1211.434930] smsc911x_poll dropped(0) pktwords(268) pktlength(1070) netif_receive(0) rx_packets(148) rx_bytes(150726)
[ 1211.466585] 0000|9d 08 ed 51 00 00 00 00-0e 05 0c 00 00 00 00 00|..íQ............
[ 1211.489102] 0010|10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f|................
[ 1211.511614] 0020|20 21 22 23 24 25 26 27-28 29 2a 2b 2c 2d 2e 2f| !"#$%&'()*+,-./
[ 1211.534124] 0030|30 31 32 33 34 35 36 37-38 39 3a 3b 3c 3d 3e 3f|0123456789:;<=>?
[ 1211.556634] 0040|40 41 42 43 44 45 46 47-48 49 4a 4b 4c 4d 4e 4f|#ABCDEFGHIJKLMNO
[ 1211.579145] 0050|50 51 52 53 54 55 56 57-58 59 5a 5b 5c 5d 5e 5f|PQRSTUVWXYZ[\]^_
[ 1211.601655] 0060|60 61 62 63 64 65 66 67-68 69 6a 6b 6c 6d 6e 6f|`abcdefghijklmno
[ 1211.624164] 0070|70 71 72 73 74 75 76 77-78 79 7a 7b 7c 7d 7e 7f|pqrstuvwxyz{|}~.
[ 1211.646674] 0080|80 81 82 83 84 85 86 87-88 89 8a 8b 8c 8d 8e 8f|................
[ 1211.669184] 0090|90 91 92 93 94 95 96 97-98 99 9a 9b 9c 9d 9e 9f|................
[ 1211.691694] 00a0|a0 a1 a2 a3 a4 a5 a6 a7-a8 a9 aa ab ac ad ae af| ¡¢£¤¥¦§¨©ª«¬®¯
[ 1211.714203] 00b0|b0 b1 b2 b3 b4 b5 b6 b7-b8 b9 ba bb bc bd be bf|°±²³´µ¶·¸¹º»¼½¾¿
[ 1211.736713] 00c0|c0 c1 c2 c3 c4 c5 c6 c7-c8 c9 ca cb cc cd ce cf|ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
[ 1211.759223] 00d0|d0 d1 d2 d3 d4 d5 d6 d7-d8 d9 da db dc dd de df|ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß
[ 1211.781732] 00e0|e0 e1 e2 e3 e4 e5 e6 e7-e8 e9 ea eb ec ed ee ef|àáâãäåæçèéêëìíîï
[ 1211.804242] 00f0|f0 f1 f2 f3 f4 f5 f6 f7-f8 f9 fa fb fc fd fe ff|ðñòóôõö÷øùúûüýþÿ
[ 1211.826752] 0100|00 01 02 03 04 05 06 07-08 09 0a 0b __ __ __ __|............____
[ 1212.436944] smsc911x_poll dropped(0) pktwords(268) pktlength(1070) netif_receive(0) rx_packets(149) rx_bytes(151792)
[ 1212.468601] 0000|08 00 e9 ae 0a 1a 00 11-9e 08 ed 51 00 00 00 00|..é®......íQ....
[ 1212.491116] 0010|a4 0c 0c 00 00 00 00 00-10 11 12 13 14 15 16 17|¤...............
[ 1212.513629] 0020|18 19 1a 1b 1c 1d 1e 1f-20 21 22 23 24 25 26 27|........ !"#$%&'
[ 1212.536139] 0030|28 29 2a 2b 2c 2d 2e 2f-30 31 32 33 34 35 36 37|()*+,-./01234567
[ 1212.558650] 0040|38 39 3a 3b 3c 3d 3e 3f-40 41 42 43 44 45 46 47|89:;<=>?#ABCDEFG
[ 1212.581160] 0050|48 49 4a 4b 4c 4d 4e 4f-50 51 52 53 54 55 56 57|HIJKLMNOPQRSTUVW
[ 1212.603669] 0060|58 59 5a 5b 5c 5d 5e 5f-60 61 62 63 64 65 66 67|XYZ[\]^_`abcdefg
[ 1212.626179] 0070|68 69 6a 6b 6c 6d 6e 6f-70 71 72 73 74 75 76 77|hijklmnopqrstuvw
[ 1212.648689] 0080|78 79 7a 7b 7c 7d 7e 7f-80 81 82 83 84 85 86 87|xyz{|}~.........
[ 1212.671198] 0090|88 89 8a 8b 8c 8d 8e 8f-90 91 92 93 94 95 96 97|................
[ 1212.693709] 00a0|98 99 9a 9b 9c 9d 9e 9f-a0 a1 a2 a3 a4 a5 a6 a7|........ ¡¢£¤¥¦§
[ 1212.716219] 00b0|a8 a9 aa ab ac ad ae af-b0 b1 b2 b3 b4 b5 b6 b7|¨©ª«¬®¯°±²³´µ¶·
[ 1212.738728] 00c0|b8 b9 ba bb bc bd be bf-c0 c1 c2 c3 c4 c5 c6 c7|¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇ
[ 1212.761238] 00d0|c8 c9 ca cb cc cd ce cf-d0 d1 d2 d3 d4 d5 d6 d7|ÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×
[ 1212.783747] 00e0|d8 d9 da db dc dd de df-e0 e1 e2 e3 e4 e5 e6 e7|ØÙÚÛÜÝÞßàáâãäåæç
[ 1212.806257] 00f0|e8 e9 ea eb ec ed ee ef-f0 f1 f2 f3 f4 f5 f6 f7|èéêëìíîïðñòóôõö÷
[ 1212.828767] 0100|f8 f9 fa fb fc fd fe ff-00 01 02 03 __ __ __ __|øùúûüýþÿ....____
[ 1213.437206] smsc911x_poll dropped(0) pktwords(268) pktlength(1070) netif_receive(1) rx_packets(150) rx_bytes(152858)
[ 1213.468860] 0000|52 2e 08 00 45 00 04 1c-00 00 40 00 40 01 1b 89|R...E.....#.#...
[ 1213.491374] 0010|0a 00 03 c3 0a 00 03 96-08 00 b0 ad 0a 1a 00 12|...Ã......°....
[ 1213.513885] 0020|9f 08 ed 51 00 00 00 00-dc 0c 0c 00 00 00 00 00|..íQ....Ü.......
[ 1213.536396] 0030|10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f|................
[ 1213.558906] 0040|20 21 22 23 24 25 26 27-28 29 2a 2b 2c 2d 2e 2f| !"#$%&'()*+,-./
[ 1213.581415] 0050|30 31 32 33 34 35 36 37-38 39 3a 3b 3c 3d 3e 3f|0123456789:;<=>?
[ 1213.603925] 0060|40 41 42 43 44 45 46 47-48 49 4a 4b 4c 4d 4e 4f|#ABCDEFGHIJKLMNO
[ 1213.626435] 0070|50 51 52 53 54 55 56 57-58 59 5a 5b 5c 5d 5e 5f|PQRSTUVWXYZ[\]^_
[ 1213.648944] 0080|60 61 62 63 64 65 66 67-68 69 6a 6b 6c 6d 6e 6f|`abcdefghijklmno
[ 1213.671454] 0090|70 71 72 73 74 75 76 77-78 79 7a 7b 7c 7d 7e 7f|pqrstuvwxyz{|}~.
[ 1213.693964] 00a0|80 81 82 83 84 85 86 87-88 89 8a 8b 8c 8d 8e 8f|................
[ 1213.716474] 00b0|90 91 92 93 94 95 96 97-98 99 9a 9b 9c 9d 9e 9f|................
[ 1213.738983] 00c0|a0 a1 a2 a3 a4 a5 a6 a7-a8 a9 aa ab ac ad ae af| ¡¢£¤¥¦§¨©ª«¬®¯
[ 1213.761493] 00d0|b0 b1 b2 b3 b4 b5 b6 b7-b8 b9 ba bb bc bd be bf|°±²³´µ¶·¸¹º»¼½¾¿
[ 1213.784003] 00e0|c0 c1 c2 c3 c4 c5 c6 c7-c8 c9 ca cb cc cd ce cf|ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
[ 1213.806513] 00f0|d0 d1 d2 d3 d4 d5 d6 d7-d8 d9 da db dc dd de df|ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß
[ 1213.829023] 0100|e0 e1 e2 e3 e4 e5 e6 e7-e8 e9 ea eb __ __ __ __|àáâãäåæçèéêë____
[ 1214.437438] smsc911x_poll dropped(0) pktwords(268) pktlength(1070) netif_receive(1) rx_packets(151) rx_bytes(153924)
[ 1214.469092] 0000|52 2e 08 00 45 00 04 1c-00 00 40 00 40 01 1b 89|R...E.....#.#...
[ 1214.491605] 0010|0a 00 03 c3 0a 00 03 96-08 00 b3 ac 0a 1a 00 13|...Ã......³¬....
[ 1214.514117] 0020|a0 08 ed 51 00 00 00 00-d8 0c 0c 00 00 00 00 00| .íQ....Ø.......
[ 1214.536627] 0030|10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f|................
[ 1214.559138] 0040|20 21 22 23 24 25 26 27-28 29 2a 2b 2c 2d 2e 2f| !"#$%&'()*+,-./
[ 1214.581645] 0050|30 31 32 33 34 35 36 37-38 39 3a 3b 3c 3d 3e 3f|0123456789:;<=>?
[ 1214.604154] 0060|40 41 42 43 44 45 46 47-48 49 4a 4b 4c 4d 4e 4f|#ABCDEFGHIJKLMNO
[ 1214.626664] 0070|50 51 52 53 54 55 56 57-58 59 5a 5b 5c 5d 5e 5f|PQRSTUVWXYZ[\]^_
[ 1214.649174] 0080|60 61 62 63 64 65 66 67-68 69 6a 6b 6c 6d 6e 6f|`abcdefghijklmno
[ 1214.671684] 0090|70 71 72 73 74 75 76 77-78 79 7a 7b 7c 7d 7e 7f|pqrstuvwxyz{|}~.
[ 1214.694194] 00a0|80 81 82 83 84 85 86 87-88 89 8a 8b 8c 8d 8e 8f|................
[ 1214.716703] 00b0|90 91 92 93 94 95 96 97-98 99 9a 9b 9c 9d 9e 9f|................
[ 1214.739213] 00c0|a0 a1 a2 a3 a4 a5 a6 a7-a8 a9 aa ab ac ad ae af| ¡¢£¤¥¦§¨©ª«¬®¯
[ 1214.761723] 00d0|b0 b1 b2 b3 b4 b5 b6 b7-b8 b9 ba bb bc bd be bf|°±²³´µ¶·¸¹º»¼½¾¿
[ 1214.784233] 00e0|c0 c1 c2 c3 c4 c5 c6 c7-c8 c9 ca cb cc cd ce cf|ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
[ 1214.806742] 00f0|d0 d1 d2 d3 d4 d5 d6 d7-d8 d9 da db dc dd de df|ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß
[ 1214.829252] 0100|e0 e1 e2 e3 e4 e5 e6 e7-e8 e9 ea eb __ __ __ __|àáâãäåæçèéêë____