I'm using BlueZ for handling BLE devices. I have compiled it from source, and wrote a wrapper around it.
I'm searching for this tiny bit of information:
What is "LE Read Remote Used Features" command for?
Which features can it read?
Is this mandatory for connecting to a BLE device?
Is it safe to disable querying it after connection?
Is it possible to increase the timeout for the reception of this command's response?
My problem is that my solution works with some devices already (can connect to them), but with a particular device, many times connection fails due to timeout.
I've created a sniff with btmon when the connection fails:
# btmon
Bluetooth monitor ver 5.50
= Note: Linux version 4.19.97-v7l+ (armv7l) 0.742019
= Note: Bluetooth subsystem version 2.22 0.742027
= New Index: AA:BB:CC:DD:EE:FF (Primary,UART,hci0) [hci0] 0.742030
= Open Index: AA:BB:CC:DD:EE:FF [hci0] 0.742033
= Index Info: AA:BB:CC:D.. (Cypress Semiconductor Corporation) [hci0] 0.742035
# MGMT Open: bluetoothd (privileged) version 1.14 {0x0001} 0.742038
# MGMT Open: btmon (privileged) version 1.14 {0x0002} 0.742321
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #1 [hci0] 4.737267
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #2 [hci0] 4.737714
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #3 [hci0] 4.737767
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] 4.738160
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 42 #5 [hci0] 6.099681
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Public (0x00)
Address: FF:EE:DD:CC:BB:AA
Data length: 30
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Apple, Inc. (76)
Type: iBeacon (2)
UUID: 669a0c20-0008-6c91-e411-015500e22ea9
Version: 48661.62728
TX power: -59 dB
RSSI: -78 dBm (0xb2)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #6 [hci0] 6.099747
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #7 [hci0] 6.101862
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25 #8 [hci0] 6.101916
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: FF:EE:DD:CC:BB:AA
Own address type: Public (0x00)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #9 [hci0] 6.102446
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 #10 [hci0] 7.476997
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Master (0x00)
Peer address type: Public (0x00)
Peer address: FF:EE:DD:CC:BB:AA
Connection interval: 48.75 msec (0x0027)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
# MGMT Event: Device Connected (0x000b) plen 43 {0x0002} [hci0] 7.477047
LE Address: FF:EE:DD:CC:BB:AA
Flags: 0x00000000
Data length: 30
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Apple, Inc. (76)
Type: iBeacon (2)
UUID: 669a0c20-0008-6c91-e411-015500e22ea9
Version: 48661.62728
TX power: -59 dB
# MGMT Event: Device Connected (0x000b) plen 43 {0x0001} [hci0] 7.477047
LE Address: FF:EE:DD:CC:BB:AA
Flags: 0x00000000
Data length: 30
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Apple, Inc. (76)
Type: iBeacon (2)
UUID: UUID
Version: 48661.62728
TX power: -59 dB
< HCI Command: LE Read Remote Used... (0x08|0x0016) plen 2 #11 [hci0] 7.477210
Handle: 64
> HCI Event: Command Status (0x0f) plen 4 #12 [hci0] 7.479342
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 14 #13 [hci0] 7.479357
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
00 00 00 00 00 00 00 00 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 12 #14 [hci0] 7.993969
LE Read Remote Used Features (0x04)
Status: Connection Timeout (0x08)
Handle: 64
Features: 0x2d 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Extended Reject Indication
Slave-initiated Features Exchange
LE Data Packet Length Extension
> HCI Event: Disconnect Complete (0x05) plen 4 #15 [hci0] 7.994591
Status: Success (0x00)
Handle: 64
Reason: Connection Timeout (0x08)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0002} [hci0] 8.027693
LE Address: FF:EE:DD:CC:BB:AA
Reason: Connection timeout (0x01)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 8.027693
LE Address: FF:EE:DD:CC:BB:AA
Reason: Connection timeout (0x01)
The connection first succeeds, but then my device executes a "LE Read Remote Used Features" HCI Command which times out after 500ms causes the whole connection to fail.
This is my reason for hunting the answers for the questions above.
Answers to all your questions can be found in the Bluetooth Core specification in the Link Layer chapter.
What happens is that the connection drops to the remote device. Bad signal quality? Bad antenna? Bad clock accuracy?
The connection timeout happens after the specified supervision timeout if no packets (possibly empty) are received within this time.
Now it just happens that the first thing BlueZ sends is a remote feature request. If any other packets were sent instead, you'd likely get the same result (connection timeout).
Use a BLE link layer sniffer instead to see what really happens.
I had a similar problem, here are my findings:
What is "LE Read Remote Used Features" command for?
As #Emil pointed out, this command was in the BT Spec, until 5.0. So In BT Spec 4.2 it says:
This command requests a list of the used LE features from the remote device.
This command shall return a list of the used LE features
You need to have an idea on what the Remote is capable of before expecting it to do things right ?
Which features can it read?
After increasing the timeout from 500ms to the upper limit 32000ms the result was
as follows:
Handle: 128
HCI Event: Command Status (0x0f) plen 4
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
HCI Event: LE Meta Event (0x3e) plen 11
LE Data Length Change (0x07)
Handle: 128
Max TX octets: 251
Max TX time: 17040
Max RX octets: 251
Max RX time: 17040
HCI Event: LE Meta Event (0x3e) plen 12
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 128
Features: 0x7f 0xfb 0x46 0x07 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
LE Data Packet Length Extension
LL Privacy
LE 2M PHY
Stable Modulation Index - Transmitter
LE Coded PHY
LE Extended Advertising
LE Periodic Advertising
Channel Selection Algorithm #2
LE Power Class 1
Unknown features (0x0000000007460000)
Is it safe to disable querying it after connection?
In my case the culprit was not this command that sabotaged the connection. I'd advice to increase the timeout amount and see what happens.
Is it possible to increase the timeout for the reception of this command's response?
If you were to issue this command separately and if it included such a parameter, then yes why not? In my case it's using what ever Supervision timeout I have provided to the (Extended)Create Connection command.
Related
I have been trying out the bluez btmon tool to monitor the bluetooth discovery result on my raspberry pi 4.
The btmon tool returns stdout which is the following:
# MGMT Event: Device Found (0x0012) plen 42 {0x0001} [hci0] 0.207973
LE Address: 61:E1:E1:49:C8:DC (Resolvable)
RSSI: -51 dBm (0xcd)
Flags: 0x00000004
Not Connectable
Data length: 28
16-bit Service UUIDs (complete): 1 entry
Google (0xfe9f)
Service Data (UUID 0xfe9f): 0000000000000000000000000000000000000000
# MGMT Event: Device Found (0x0012) plen 33 {0x0001} [hci0] 0.224956
LE Address: 48:82:8F:DB:5C:65 (Resolvable)
RSSI: -76 dBm (0xb4)
Flags: 0x00000000
Data length: 19
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 5 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 491faeca8c8638
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.298194
LE Address: 0E:AF:D9:F0:D8:F1 (Non-Resolvable)
RSSI: -68 dBm (0xbc)
Flags: 0x00000004
Not Connectable
Data length: 29
Company: Microsoft (6)
Data: 0109210a065124d7b5c04445534b544f502d44484845413434
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.940219
LE Address: 86:2A:FD:9E:57:0D (OUI 86-2A-FD)
RSSI: -77 dBm (0xb3)
Flags: 0x00000000
Data length: 29
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Service Data (UUID 0xfdf7): 01384a3dd6381b593c74d9369eefaa9b720000000003
Been looking for some official docs on explaining the field "Flags" in each discovered device info (those flag codes: 0x00000004, 0x00000000, 0x1a, 0x06), but I couldn't seem to find one that makes sense.
Would really appreciate if anyone could explain what does the Flags tell, and how to make sense of these codes?
Thanks in advance.
I don't know what you call "official docs", but the Bluetooth Core Specification and the Supplement to the Bluetooth Core Specification certainly explains it. Have a look at chapter 1.3 FLAGS of CSS
In the log you showed, you can see the advertising data of several Bluetooth LE devices. Each of this advertising data contains one ore more fields called AD Types. One of the AD Types is the "Flags" field. It may be zero or more octets long, with the first octet containing the following information:
Octet
Bit
Description
0
0
LE Limited Discoverable Mode
0
1
LE General Discoverable Mode
0
2
BR/EDR Not Supported. Bit 37 of LMP Feature Mask Definitions (Page 0)
0
3
Simultaneous LE and BR/EDR to Same Device Capable (Controller). Bit 49 of LMP Feature Mask Definitions (Page 0)
0
4
Previously Used
0
5..7
Reserved for future use
The given information tells you something about the used Bluetooth radio and about the advertising itself. If you are interested in a deeper understanding of this topic, I recommend reading this Bluetooth blog article: Advertising Works, Part 1
In prior kernels and releases of Ubuntu, it was possible to use the hci socket interface to send an arbitrary set of 31 bytes as an advertising beacon, but in ubuntu 20.04 the hci bluetooth tools were deprecated, as were some elements of the socket API they were using.
The goal is to have some N number of devices broadcast 31 bytes of sensor data to each other at a rate of 5 Hz, and have all N read the packets from the other devices.
With the hci socket API being deprecated, the replacements are the DBus BlueZ API and the Management BlueZ API. The DBus API is limited and seems to only allow a max of 25 bytes. The Management API seems more capable, and it seems to work on Ubuntu 18.04/4.15 kernel (though even there the scan seemed to only pick up the advertisements sporadically when switching between scan and advertise every 100ms while with the hci api it was rock solid), but on Ubuntu 20.04/5.4 kernel, various issues crop up.
Using the hci socket API seems like it could still be possible, but even running something like hcitool lescan results in btmon saying Command Disallowed. I believe this might be due to LE Extended Advertising being enabled, but I have not figured out how to disable it yet.
Using the DBus API (or bluetoothctl) is still limited and doesn't allow the full use of the 31 bytes (or even 30 bytes + length)
Using the Management API leads to a Advertising Timeout shortly after setting the advertising data, which I think might be from LE Extended Advertising being enabled. This problem persists even if I explicitly set the timeout in the packet.
For example, running
btmgmt add-adv -c -d 1E000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D 1
to send an advertising packet at a fixed MAC with the advertising data being length:31 payload: 0-30 results in a btmon output of:
< HCI Command:... (0x08|0x0036) plen 25 #631 [hci0] 5676.358401
Handle: 0x01
Properties: 0x0013
Connectable
Scannable
Use legacy advertising PDUs: ADV_IND
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: 127 dbm (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
> HCI Event: Command Co.. (0x0e) plen 5 #632 [hci0] 5676.359321
LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
Status: Success (0x00)
TX power (selected): 7 dbm (0x07)
< HCI Command: L.. (0x08|0x0039) plen 6 #633 [hci0] 5676.359410
Extended advertising: Enabled (0x01)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x01
Duration: 2000 ms (0xc8)
Max ext adv events: 0
> HCI Event: Command Co.. (0x0e) plen 4 #634 [hci0] 5676.361330
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
# MGMT Event: Com.. (0x0001) plen 4 {0x0003} [hci0] 5676.361372
Add Advertising (0x003e) plen 1
Status: Success (0x00)
Instance: 1
> HCI Event: LE Meta Ev.. (0x3e) plen 6 #635 [hci0] 5676.362333
LE Advertising Set Terminated (0x12)
Status: Advertising Timeout (0x3c)
Handle: 1
Connection handle: 65535
Number of completed extended advertising events: 0
Is there a good way to recreate the functionality that was available using the hci socket, or a way to disable extended advertising so that the hci socket works again?
This image from Jos Ryke might help explain what is going on. Of those 31 bytes, 3 were always used for setting the advertising flags.
Looking at the source code for btmgmt those flags are now set with the -g, and -l command line switches. Use general discoverable mode to advertise indefinitely.
static void add_adv_usage(void)
{
bt_shell_usage();
print("Options:\n"
"\t -u, --uuid <uuid> Service UUID\n"
"\t -d, --adv-data <data> Advertising Data bytes\n"
"\t -s, --scan-rsp <data> Scan Response Data bytes\n"
"\t -t, --timeout <timeout> Timeout in seconds\n"
"\t -D, --duration <duration> Duration in seconds\n"
"\t -P, --phy <phy> Phy type, Specify 1M/2M/CODED\n"
"\t -c, --connectable \"connectable\" flag\n"
"\t -g, --general-discov \"general-discoverable\" flag\n"
"\t -l, --limited-discov \"limited-discoverable\" flag\n"
"\t -n, --scan-rsp-local-name \"local-name\" flag\n"
"\t -a, --scan-rsp-appearance \"appearance\" flag\n"
"\t -m, --managed-flags \"managed-flags\" flag\n"
"\t -p, --tx-power \"tx-power\" flag\n"
"e.g.:\n"
"\tadd-adv -u 180d -u 180f -d 080954657374204C45 1");
}
The other 28 bytes must start with a byte declaring the length and a byte declaring what data type the rest of the bytes in the declared length are describing.
It is those 28 bytes that is being set with the -d option of btmgmt.
If 28 bytes are not enough, then common workarounds people use is to split the data over multiple adverts or use scan response packet.
There is more detail on the Advertising Data Format in the Core Specification where it defines an Advertising Packet as:
A packet containing an advertising PDU. See [Vol 6]
Part B, Section 2.3.1
More data is section:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C | 11 ADVERTISING AND SCAN RESPONSE DATA FORMAT
It has an example for ADV_NONCONN_IND packet type:
PDU Type: 2
ChSel: RFU
TxAdd: 1 (random)
RxAdd: RFU
AdvA: 0xC1A2A3A4A5A6 (a static device address)
AdvData: (3 octets) 0x01 0x02 0x03
Which starts with the flags data type.
I have a Raspberry Pi 3 running the latest Raspbian, and I have
upgraded bluez from 5.23. to 5.43. I am attempting to connect to BLE
devices that advertise at 2 second interval. I wrote some code based
on gatttool and attempted to connect to these devices. I run into the
LE connect request being cancelled after 2 seconds. Thus I get a LE Connection Complete messages with a status of 0x02 (Unknown Connection Identifier)
From my research I ran across this from about 15 months ago in the archives,
https://www.spinics.net/lists/linux-bluetooth/msg65434.html
However after following the threads, I did not see if a resolution was found.
I have ran tests with my code, the gatttool utility and well as using
bluetoothctl. I see the same type of activity in btmon that is listed
below:
HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 [hci0] 21:45:51.917070
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:51.917819
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:51.918357
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 27 [hci0] 21:45:52.597503
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: D3:67:2D:D1:46:46 (Static)
Data length: 15
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: FedEx Services (321)
Data: 070a111080d28004
RSSI: -63 dBm (0xc1)
HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:52.599626
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
HCI Event: Command Status (0x0f) plen 4 [hci0] 21:45:52.600508
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:54.684146
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 21:45:54.684361
LE Connection Complete (0x01)
Status: Unknown Connection Identifier (0x02)
Handle: 64
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: D3:67:2D:D1:46:46 (Static)
Connection interval: 67.50 msec (0x0036)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
# Connect Failed: D3:67:2D:D1:46:46 (2) status 0x02
It looks like there is a 2 second timeout somewhere in the code, perhaps kernel side.
One thing to note is if I use hcitool to connect, I am able to connect
most all of the time. I know this is not the L2CAP layer, but I can
see that I am able to connect.
Also, if I change the advertising interval of the BLE devices to 1 second. I can connect just fine. (Reason for 2 sec advertising interval is power savings)
Has anyone recently ran into this issue, and if so has there been any resolution?
Thanks
Having the same issue. Reducing the advertisement interval, as you've noted, from 10s to 0.5s does fix the issue. I, also, need a longer interval to conserve battery. I know that using an older build of Raspbian ( 2016-03-18-raspbian-jessie kernel 4.1.19-v7+ #858 SMP, bluez 5.23 ) works fine, however, I have yet to get a newer build to work.
UPDATE
After discovering this post: https://www.spinics.net/lists/linux-bluetooth/msg67800.html I changed the following values in include/net/bluetooth/hci.h:
#define HCI_LE_CONN_TIMEOUT msecs_to_jiffies(22000) /* 22 seconds WAS 2 seconds */
#define HCI_LE_AUTOCONN_TIMEOUT msecs_to_jiffies(22000) /* 22 seconds WAS 2 seconds */
recompiled, and all is working now with a 10.24 second broadcast interval from my device on the latest version of Raspbian kernel 4.4.50 with bluez 5.45. Hope this helps.
As Troy E. Lanes noted, this is due to a short HCI_LE_AUTOCONN_TIMEOUT defined in the kernel. If the timeout expired after LE Create Connection command is sent, the host sends command LE Create Connection Cancel.
But you can change timeout value without recompiling the kernel. I made a tool to change LE autoconnect timeout https://gist.github.com/mironovdm/cb7f47e8d898e9a3977fc888d990e8a9
I am trying to connect a Wahoo Scale 1.3 to read the live weight of a person via bluetooth notifications.
The live weight can be read via the following characteristic:
handle: 0x0025, char properties: 0x10, char value handle: 0x0026, uuid: 00002b01-0000-1000-8000-00805f9b34fb.
This is working with LightBlue app on my iPhone.
When I try to receive notifications via gatttool I get the following error:
Command line gatttool: (tried also lots of different notations from different stack overflow topics)
[XX:XX:XX:XX:XX:XX][LE]> char-write-req 0x0026 0100
Error: Characteristic Write Request failed: Attribute can't be written
btmon bluetooth log
< ACL Data TX: Handle 0 flags 0x00 dlen 9 [hci0] 4.291021
ATT: Write Request (0x12) len 4
Handle: 0x0026
Data: 0100
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 4.327199
Num handles: 1
Handle: 0
Count: 1
> ACL Data RX: Handle 0 flags 0x02 dlen 9 [hci0] 4.383580
ATT: Error Response (0x01) len 4
Write Request (0x12)
Handle: 0x0026
Error: Write Not Permitted (0x03)
One thing I noticed is that under UUID 1901 (weight service) there are 3 properties: 1: write/indicate, 2: notify, 3: notify.
Bluetooth characteristics on LightBlue App
I am able to write with gatttool to the first property, but not to the 2 and 3 property. But how does LightBlue starts listening for notifications?
I tried this one two different systems:
Beaglebone Black with QN9021 BLE controller (Bluez 5.38, OpenWrt Linux 4.4)
Beaglebone Black WiFi/Bluetooth (Bluez 5.23, Debian Linux 4.4)
Do I get this error because of incompatiblities of the Bluez stack and the Wahoo Scale? How do I fix this?
Thank you!
0x0026 is the handle for the value, not for the descriptor. I would guess the descriptor's handle is 0x0027.
Hi I am going through hci_send_req implementation in hci.c file. in this function after sending hci command to controller . Controller send event packet. After reading event packet in buffer by read(dd, buf, sizeof(buf)) (dd is hci socket descriptor) , now we need event packet header and to get event packet header, buf is sifted by 1 byte. why??
hdr = (void *) (buf + 1); (line number 1049 of hci.c)
Please let me know about this. Thanks.
HCI Event Packets: the Host Controller notifies the HCI Driver of events:
Packet indicator (for UART interfaces) of 4.
Event code (8 bits): identifies the event.
Parameter length (8-bit): total length of all parameters in bytes.
Event parameters: the number of parameters and their length is event specific.
So first octet is for Packet indicator that is 0x04 for event packet.
for command packet - 0x01 (for UART interface)
for ACL data packet - 0x02 (for UART interface)
for SCO data packet - 0x03 (for UART interface)