* Disabled bluetooth cache. But the app still getting wrong data?
@ 2021-04-13 5:59 Kenny Bian
2021-04-13 6:39 ` Jamie Mccrae
0 siblings, 1 reply; 13+ messages in thread
From: Kenny Bian @ 2021-04-13 5:59 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
Previously we had an issue: if there is a change of characteristics in
the new build of our firmware, then the app will get the wrong data.
By saying changed characteristics, it can be an added or removed
characteristic, or adding notification to an existing characteristic.
In order to keep the pairing information, the "/var/lib/bluetooth"
folder is copied over to the new build's partition. We realized that
there is no "service changed indication". The app can't handle the
changed services. So we disabled the bluetooth cache by set this in
"/etc/bluetooth/main.conf":
[GATT]
Cache = no
But recently, we saw the problem again even if the bluetooth cache is
disabled: in the build number 101, a characteristic is removed. But
when we upgrade the build from 100 to 101, the app gets the wrong
data. We looked at the log. When the app tries to read temperature by
using the temperature UUID, somehow the bluetooth service we created
received the request to read the "device name"(device name UUID). So
the "device name" is returned to the app as the temperature. This
looks like the same behavior as the bluetooth cache is not disabled. I
looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no
"[Attributes]" section in the files in the folder. That means the
disabled cache seems working.
The only way to fix this issue is to force exit the mobile app on the
phone and "Forget This Device" in iOS or "Unpair" in Android.
I looked at the btmon(see attached). For the working btmon log, there
is "Attribute group list: XX entries" under "ACL Data TX". But there
is no "Attribute group list: XX entries" under "ACL Data TX" in the
attached problematic btmon log.
Questions:
1. How is it possible that this still happens even if the bluetooth
cache is disabled?
2. Is this the problem on the Linux side which runs the GATT server or
on the mobile side?
3. Is there anything else we should look into?
We're going to release our product soon. This is a critical issue for
us. Please help if you have any suggestions.
Thanks!
[-- Attachment #2: btmon_ios_wrongdata.log --]
[-- Type: application/octet-stream, Size: 98304 bytes --]
Bluetooth monitor ver 5.48
= Note: Linux version 4.19.35-g4e7ddffd720 (armv7l) 0.539517
= Note: Bluetooth subsystem version 2.22 0.539532
= New Index: 00:16:A4:5B:4F:02 (Primary,UART,hci0) [hci0] 0.539537
= Open Index: 00:16:A4:5B:4F:02 [hci0] 0.539541
= Index Info: 00:16:A4:5.. (Cypress Semiconductor Corporation) [hci0] 0.539544
@ MGMT Open: bluetoothd (privileged) version 1.14 {0x0002} 0.539549
@ MGMT Open: bluetoothd (privileged) version 1.14 {0x0001} 0.539552
@ MGMT Open: btmon (privileged) version 1.14 {0x0003} 0.539625
< HCI Command: LE Set Advertising D.. (0x08|0x0008) plen 32 #1 [hci0] 1.687732
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #2 [hci0] 1.690438
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 #3 [hci0] 1.690553
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] 1.692488
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising P.. (0x08|0x0006) plen 15 #5 [hci0] 1.692591
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #6 [hci0] 1.698081
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 #7 [hci0] 1.698180
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #8 [hci0] 1.699297
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising D.. (0x08|0x0008) plen 32 #9 [hci0] 3.767747
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #10 [hci0] 3.769253
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Ena.. (0x08|0x000a) plen 1 #11 [hci0] 3.769359
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #12 [hci0] 3.770871
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising... (0x08|0x0006) plen 15 #13 [hci0] 3.770971
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #14 [hci0] 3.773388
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Ena.. (0x08|0x000a) plen 1 #15 [hci0] 3.773494
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #16 [hci0] 3.774888
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising... (0x08|0x0008) plen 32 #17 [hci0] 5.847528
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #18 [hci0] 5.851890
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Ena.. (0x08|0x000a) plen 1 #19 [hci0] 5.852133
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #20 [hci0] 5.858188
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising... (0x08|0x0006) plen 15 #21 [hci0] 5.858404
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #22 [hci0] 5.860285
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Ena.. (0x08|0x000a) plen 1 #23 [hci0] 5.860512
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #24 [hci0] 5.862384
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising... (0x08|0x0008) plen 32 #25 [hci0] 7.927261
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #26 [hci0] 7.929157
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Ena.. (0x08|0x000a) plen 1 #27 [hci0] 7.929241
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #28 [hci0] 7.930777
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising... (0x08|0x0006) plen 15 #29 [hci0] 7.930857
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #30 [hci0] 7.933341
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Ena.. (0x08|0x000a) plen 1 #31 [hci0] 7.933432
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #32 [hci0] 7.934877
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising.. (0x08|0x0008) plen 32 #33 [hci0] 10.007307
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #34 [hci0] 10.009298
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise En.. (0x08|0x000a) plen 1 #35 [hci0] 10.009403
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #36 [hci0] 10.011149
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising.. (0x08|0x0006) plen 15 #37 [hci0] 10.011255
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #38 [hci0] 10.016829
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise En.. (0x08|0x000a) plen 1 #39 [hci0] 10.016929
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #40 [hci0] 10.018045
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising.. (0x08|0x0008) plen 32 #41 [hci0] 12.087988
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #42 [hci0] 12.089688
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise En.. (0x08|0x000a) plen 1 #43 [hci0] 12.089794
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #44 [hci0] 12.091943
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising.. (0x08|0x0006) plen 15 #45 [hci0] 12.092051
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #46 [hci0] 12.098073
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise En.. (0x08|0x000a) plen 1 #47 [hci0] 12.098178
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #48 [hci0] 12.099471
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 #49 [hci0] 12.105968
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Slave (0x01)
Peer address type: Random (0x01)
Peer address: 66:42:DF:2C:C7:48 (Resolvable)
Connection interval: 30.00 msec (0x0018)
Connection latency: 0 (0x0000)
Supervision timeout: 720 msec (0x0048)
Master clock accuracy: 0x05
@ MGMT Event: Device Connected (0x000b) plen 13 {0x0003} [hci0] 12.106092
LE Address: 6C:96:CF:98:99:12 (Apple, Inc.)
Flags: 0x00000000
Data length: 0
@ MGMT Event: Device Connected (0x000b) plen 13 {0x0002} [hci0] 12.106092
LE Address: 6C:96:CF:98:99:12 (Apple, Inc.)
Flags: 0x00000000
Data length: 0
@ MGMT Event: Device Connected (0x000b) plen 13 {0x0001} [hci0] 12.106092
LE Address: 6C:96:CF:98:99:12 (Apple, Inc.)
Flags: 0x00000000
Data length: 0
< HCI Command: LE Read Remote Used.. (0x08|0x0016) plen 2 #50 [hci0] 12.106419
Handle: 64
> HCI Event: Command Status (0x0f) plen 4 #51 [hci0] 12.125657
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 13 #52 [hci0] 12.280095
LE Long Term Key Request (0x05)
Handle: 64
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
< HCI Command: LE Long Term Key R.. (0x08|0x001a) plen 18 #53 [hci0] 12.280195
Handle: 64
Long term key: 6bd03e98a5caaf183fac20180e3ad49e
> HCI Event: Command Complete (0x0e) plen 6 #54 [hci0] 12.283639
LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
Status: Success (0x00)
Handle: 64
> HCI Event: Encryption Change (0x08) plen 4 #55 [hci0] 12.400577
Status: Success (0x00)
Handle: 64
Encryption: Enabled with AES-CCM (0x01)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #56 [hci0] 12.415480
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
> HCI Event: LE Meta Event (0x3e) plen 12 #57 [hci0] 12.460549
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 64
Features: 0x1d 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
> ACL Data RX: Handle 64 flags 0x02 dlen 11 #58 [hci0] 12.610121
ATT: Handle Value Indication (0x1d) len 6
Handle: 0x0008
Data: 0a00ffff
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #59 [hci0] 12.610830
ATT: Handle Value Confirmation (0x1e) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #60 [hci0] 12.611041
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 185
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #61 [hci0] 12.611639
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #62 [hci0] 12.640897
ATT: Write Request (0x12) len 4
Handle: 0x0009
Data: 0200
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #63 [hci0] 12.641724
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #64 [hci0] 12.670336
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 18 #65 [hci0] 12.730673
ATT: Read By Group Type Response (0x11) len 13
Attribute data length: 6
Attribute group list: 2 entries
Handle range: 0x0001-0x0005
UUID: Generic Access Profile (0x1800)
Handle range: 0x0006-0x0009
UUID: Generic Attribute Profile (0x1801)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #66 [hci0] 12.731201
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x000a-0xffff
Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5 #67 [hci0] 12.733753
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 27 #68 [hci0] 12.790340
> ACL Data RX: Handle 64 flags 0x01 dlen 19 #69 [hci0] 12.790947
ATT: Read By Group Type Response (0x11) len 41
Attribute data length: 20
Attribute group list: 2 entries
Handle range: 0x000a-0x000e
UUID: Vendor specific (d0611e78-bbb4-4591-a5f8-487910ae4366)
Handle range: 0x000f-0x0013
UUID: Vendor specific (9fa480e0-4967-4542-9390-d343dc5d04ae)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #70 [hci0] 12.791409
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0014-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 64 flags 0x02 dlen 24 #71 [hci0] 12.850549
ATT: Read By Group Type Response (0x11) len 19
Attribute data length: 6
Attribute group list: 3 entries
Handle range: 0x0014-0x0017
UUID: Battery Service (0x180f)
Handle range: 0x0018-0x001d
UUID: Current Time Service (0x1805)
Handle range: 0x001e-0x0022
UUID: Device Information (0x180a)
> HCI Event: Number of Completed Packets (0x13) plen 5 #72 [hci0] 12.850818
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #73 [hci0] 12.858107
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0023-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 64 flags 0x02 dlen 27 #74 [hci0] 12.910604
> ACL Data RX: Handle 64 flags 0x01 dlen 19 #75 [hci0] 12.910937
ATT: Read By Group Type Response (0x11) len 41
Attribute data length: 20
Attribute group list: 2 entries
Handle range: 0x0023-0x002c
UUID: Vendor specific (7905f431-b5ce-4e99-a40f-4b1e122d00d0)
Handle range: 0x002d-0x0038
UUID: Vendor specific (89d3502b-0f36-433a-8ef4-c502ad55f8dc)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #76 [hci0] 12.911380
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0039-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #77 [hci0] 12.970132
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0039
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #78 [hci0] 12.971068
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Secondary Service (0x2801)
> HCI Event: Number of Completed Packets (0x13) plen 5 #79 [hci0] 12.971278
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 13 #80 [hci0] 13.032011
ATT: Write Request (0x12) len 8
Handle: 0x000c
Data: 303030303030
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #81 [hci0] 13.059935
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0038
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #82 [hci0] 13.060835
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x0038
Attribute type: Include (0x2802)
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #83 [hci0] 13.091418
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #84 [hci0] 13.120225
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0038
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #85 [hci0] 13.120972
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x0038
Attribute type: Characteristic (0x2803)
> HCI Event: Number of Completed Packets (0x13) plen 5 #86 [hci0] 13.121185
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #87 [hci0] 13.149846
ATT: Read Request (0x0a) len 2
Handle: 0x0012
< ACL Data TX: Handle 64 flags 0x00 dlen 8 #88 [hci0] 13.172380
ATT: Read Response (0x0b) len 3
Value: 313032
> ACL Data RX: Handle 64 flags 0x02 dlen 27 #89 [hci0] 13.180395
ATT: Read By Type Response (0x09) len 22
Attribute data length: 7
Attribute data list: 3 entries
Handle: 0x0002
Value: 020300002a
Handle: 0x0004
Value: 020500012a
Handle: 0x0007
Value: 200800052a
> HCI Event: Number of Completed Packets (0x13) plen 5 #90 [hci0] 13.180535
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #91 [hci0] 13.181442
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0008-0x0038
Attribute type: Characteristic (0x2803)
> ACL Data RX: Handle 64 flags 0x02 dlen 13 #92 [hci0] 13.209979
ATT: Write Request (0x12) len 8
Handle: 0x000c
Data: 323232323232
> ACL Data RX: Handle 64 flags 0x02 dlen 27 #93 [hci0] 13.240482
> HCI Event: Number of Completed Packets (0x13) plen 5 #94 [hci0] 13.240742
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x01 dlen 21 #95 [hci0] 13.241025
ATT: Read By Type Response (0x09) len 43
Attribute data length: 21
Attribute data list: 2 entries
Handle: 0x000b
Value: 980c004900d927ee54ed84914c379a6c556786
Handle: 0x0010
Value: 981100cce349c57ba77a91cd43995bb1ad0baf
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #96 [hci0] 13.241694
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0011-0x0038
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #97 [hci0] 13.252205
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 27 #98 [hci0] 13.330457
> HCI Event: Number of Completed Packets (0x13) plen 5 #99 [hci0] 13.330771
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x01 dlen 14 #100 [hci0] 13.330882
ATT: Read By Type Response (0x09) len 36
Attribute data length: 7
Attribute data list: 5 entries
Handle: 0x0015
Value: 121600192a
Handle: 0x0019
Value: 121a002b2a
Handle: 0x001c
Value: 021d000f2a
Handle: 0x001f
Value: 022000292a
Handle: 0x0021
Value: 022200242a
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #101 [hci0] 13.331358
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0022-0x0038
Attribute type: Characteristic (0x2803)
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #102 [hci0] 13.331535
ATT: Read Request (0x0a) len 2
Handle: 0x0012
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #103 [hci0] 13.362546
ATT: Read Response (0x0b) len 1
Value: 30
> ACL Data RX: Handle 64 flags 0x02 dlen 27 #104 [hci0] 13.390337
> ACL Data RX: Handle 64 flags 0x01 dlen 27 #105 [hci0] 13.391226
> HCI Event: Number of Completed Packets (0x13) plen 5 #106 [hci0] 13.391452
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x01 dlen 27 #107 [hci0] 13.391724
> ACL Data RX: Handle 64 flags 0x01 dlen 27 #108 [hci0] 13.392488
> ACL Data RX: Handle 64 flags 0x01 dlen 24 #109 [hci0] 13.393265
ATT: Read By Type Response (0x09) len 127
Attribute data length: 21
Attribute data list: 6 entries
Handle: 0x0024
Value: 882500d9d9aafdbd9b2198a849e145f3d8d169
Handle: 0x0027
Value: 102800bd1da299e625588cd94201630d12bf9f
Handle: 0x002a
Value: 102b00fb7b7cce6ab344beb54bd624e9c6ea22
Handle: 0x002e
Value: 982f00c251caf7560edfb88a4ab157d8813c9b
Handle: 0x0032
Value: 98330002c196ba92bb0c9a1f418d80ceab7c2f
Handle: 0x0036
Value: 8a3700d7d5bb70a8a3aba6d846ab238cf3b2c6
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #110 [hci0] 13.394590
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0037-0x0038
Attribute type: Characteristic (0x2803)
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #111 [hci0] 13.450535
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0038
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #112 [hci0] 13.451548
ATT: Find Information Request (0x04) len 4
Handle range: 0x0009-0x0009
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #113 [hci0] 13.540721
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0009
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #114 [hci0] 13.542566
ATT: Find Information Request (0x04) len 4
Handle range: 0x000d-0x000e
> HCI Event: Number of Completed Packets (0x13) plen 5 #115 [hci0] 13.543002
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 14 #116 [hci0] 13.600596
ATT: Find Information Response (0x05) len 9
Format: UUID-16 (0x01)
Handle: 0x000d
UUID: Characteristic Extended Properties (0x2900)
Handle: 0x000e
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #117 [hci0] 13.601346
ATT: Read Request (0x0a) len 2
Handle: 0x000d
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #118 [hci0] 13.660570
ATT: Read Response (0x0b) len 2
Value: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #119 [hci0] 13.661479
ATT: Find Information Request (0x04) len 4
Handle range: 0x0012-0x0013
> HCI Event: Number of Completed Packets (0x13) plen 5 #120 [hci0] 13.661691
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 14 #121 [hci0] 13.720917
ATT: Find Information Response (0x05) len 9
Format: UUID-16 (0x01)
Handle: 0x0012
UUID: Characteristic Extended Properties (0x2900)
Handle: 0x0013
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #122 [hci0] 13.721681
ATT: Read Request (0x0a) len 2
Handle: 0x0012
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #123 [hci0] 13.780897
ATT: Read Response (0x0b) len 2
Value: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #124 [hci0] 13.781621
ATT: Find Information Request (0x04) len 4
Handle range: 0x0017-0x0017
> HCI Event: Number of Completed Packets (0x13) plen 5 #125 [hci0] 13.781812
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #126 [hci0] 13.840592
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0017
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #127 [hci0] 13.841487
ATT: Find Information Request (0x04) len 4
Handle range: 0x001b-0x001b
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #128 [hci0] 13.899972
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x001b
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #129 [hci0] 13.900791
ATT: Find Information Request (0x04) len 4
Handle range: 0x0026-0x0026
> HCI Event: Number of Completed Packets (0x13) plen 5 #130 [hci0] 13.901007
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #131 [hci0] 13.901101
ATT: Write Request (0x12) len 3
Handle: 0x0068
Data: 30
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #132 [hci0] 13.950240
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #133 [hci0] 13.960430
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0026
UUID: Characteristic Extended Properties (0x2900)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #134 [hci0] 13.961254
ATT: Read Request (0x0a) len 2
Handle: 0x0026
> HCI Event: Number of Completed Packets (0x13) plen 5 #135 [hci0] 13.989790
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #136 [hci0] 14.020535
ATT: Read Response (0x0b) len 2
Value: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #137 [hci0] 14.021226
ATT: Find Information Request (0x04) len 4
Handle range: 0x0029-0x0029
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #138 [hci0] 14.080581
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0029
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #139 [hci0] 14.081388
ATT: Find Information Request (0x04) len 4
Handle range: 0x002c-0x002c
> HCI Event: Number of Completed Packets (0x13) plen 5 #140 [hci0] 14.081603
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #141 [hci0] 14.109826
ATT: Write Request (0x12) len 3
Handle: 0x0064
Data: 32
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #142 [hci0] 14.140992
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x002c
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #143 [hci0] 14.141972
ATT: Find Information Request (0x04) len 4
Handle range: 0x0030-0x0031
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #144 [hci0] 14.158781
ATT: Write Response (0x13) len 0
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #145 [hci0] 14.167270
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #146 [hci0] 14.168753
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #147 [hci0] 14.168863
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #148 [hci0] 14.169724
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #149 [hci0] 14.169809
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #150 [hci0] 14.171111
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5 #151 [hci0] 14.200359
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 14 #152 [hci0] 14.230245
ATT: Find Information Response (0x05) len 9
Format: UUID-16 (0x01)
Handle: 0x0030
UUID: Characteristic Extended Properties (0x2900)
Handle: 0x0031
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #153 [hci0] 14.231427
ATT: Read Request (0x0a) len 2
Handle: 0x0030
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #154 [hci0] 14.231649
ATT: Write Request (0x12) len 3
Handle: 0x00ab
Data: 30
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #155 [hci0] 14.290565
ATT: Read Response (0x0b) len 2
Value: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #156 [hci0] 14.291355
ATT: Find Information Request (0x04) len 4
Handle range: 0x0034-0x0035
> HCI Event: Number of Completed Packets (0x13) plen 5 #157 [hci0] 14.291774
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #158 [hci0] 14.296487
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 14 #159 [hci0] 14.350899
ATT: Find Information Response (0x05) len 9
Format: UUID-16 (0x01)
Handle: 0x0034
UUID: Characteristic Extended Properties (0x2900)
Handle: 0x0035
UUID: Client Characteristic Configuration (0x2902)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #160 [hci0] 14.351725
ATT: Read Request (0x0a) len 2
Handle: 0x0034
> HCI Event: Number of Completed Packets (0x13) plen 5 #161 [hci0] 14.358991
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #162 [hci0] 14.359161
ATT: Write Request (0x12) len 3
Handle: 0x00a4
Data: 33
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #163 [hci0] 14.411208
ATT: Read Response (0x0b) len 2
Value: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #164 [hci0] 14.411986
ATT: Find Information Request (0x04) len 4
Handle range: 0x0038-0x0038
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #165 [hci0] 14.425303
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #166 [hci0] 14.440442
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #167 [hci0] 14.470775
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0038
UUID: Characteristic Extended Properties (0x2900)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #168 [hci0] 14.471674
ATT: Read Request (0x0a) len 2
Handle: 0x0038
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #169 [hci0] 14.530525
ATT: Read Response (0x0b) len 2
Value: 0100
> HCI Event: Number of Completed Packets (0x13) plen 5 #170 [hci0] 14.540217
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #171 [hci0] 14.585138
ATT: Write Request (0x12) len 4
Handle: 0x0009
Data: 0200
> ACL Data RX: Handle 64 flags 0x02 dlen 5 #172 [hci0] 14.649938
ATT: Write Response (0x13) len 0
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #173 [hci0] 14.713061
ATT: Read Request (0x0a) len 2
Handle: 0x0003
> ACL Data RX: Handle 64 flags 0x02 dlen 11 #174 [hci0] 14.800632
ATT: Read Response (0x0b) len 6
Value: 50686f6e6558
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #175 [hci0] 14.801370
ATT: Read Request (0x0a) len 2
Handle: 0x0005
> HCI Event: Number of Completed Packets (0x13) plen 5 #176 [hci0] 14.801588
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #177 [hci0] 14.860782
ATT: Read Response (0x0b) len 2
Value: 4000
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #178 [hci0] 14.861458
ATT: Read Request (0x0a) len 2
Handle: 0x0016
> ACL Data RX: Handle 64 flags 0x02 dlen 6 #179 [hci0] 14.920947
ATT: Read Response (0x0b) len 1
Value: 55
> HCI Event: Number of Completed Packets (0x13) plen 5 #180 [hci0] 14.921061
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #181 [hci0] 14.921771
ATT: Write Request (0x12) len 4
Handle: 0x0017
Data: 0100
> ACL Data RX: Handle 64 flags 0x02 dlen 5 #182 [hci0] 14.979901
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #183 [hci0] 15.177792
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 #184 [hci0] 15.849862
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x0005
Attribute type: Device Name (0x2a00)
< ACL Data TX: Handle 64 flags 0x00 dlen 33 #185 [hci0] 15.850919
ATT: Read By Type Response (0x09) len 28
Attribute data length: 27
Attribute data list: 1 entry
Handle: 0x0003
Value: 224f332d485542322d3278502d3132313431342f3030303722
> HCI Event: Number of Completed Packets (0x13) plen 5 #186 [hci0] 16.052874
Num handles: 1
Handle: 64
Count: 1
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #187 [hci0] 16.247486
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #188 [hci0] 16.248962
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #189 [hci0] 16.249099
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #190 [hci0] 16.251040
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #191 [hci0] 16.251221
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #192 [hci0] 16.257303
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #193 [hci0] 16.257405
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #194 [hci0] 16.258507
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #195 [hci0] 17.289822
ATT: Write Request (0x12) len 3
Handle: 0x0068
Data: 31
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #196 [hci0] 17.375657
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #197 [hci0] 17.554556
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #198 [hci0] 18.009776
ATT: Read Request (0x0a) len 2
Handle: 0x00af
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #199 [hci0] 18.033037
ATT: Read Response (0x0b) len 1
Value: 43
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #200 [hci0] 18.070710
ATT: Write Request (0x12) len 3
Handle: 0x0064
Data: 32
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #201 [hci0] 18.106996
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #202 [hci0] 18.159987
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #203 [hci0] 18.315121
ATT: Read Request (0x0a) len 2
Handle: 0x00b2
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #204 [hci0] 18.327301
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #205 [hci0] 18.328507
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #206 [hci0] 18.328609
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #207 [hci0] 18.330378
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #208 [hci0] 18.330480
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #209 [hci0] 18.336300
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #210 [hci0] 18.336408
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #211 [hci0] 18.337156
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #212 [hci0] 18.357958
ATT: Read Response (0x0b) len 2
Value: 6c78
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #213 [hci0] 18.400613
ATT: Write Request (0x12) len 3
Handle: 0x00ab
Data: 31
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #214 [hci0] 18.480179
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #215 [hci0] 18.519811
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #216 [hci0] 18.640975
ATT: Read Request (0x0a) len 2
Handle: 0x00cd
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #217 [hci0] 18.664366
ATT: Read Response (0x0b) len 4
Value: 44484350
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #218 [hci0] 18.700470
ATT: Write Request (0x12) len 3
Handle: 0x00a4
Data: 30
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #219 [hci0] 18.739069
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #220 [hci0] 18.789830
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #221 [hci0] 18.999779
ATT: Read Request (0x0a) len 2
Handle: 0x00bb
< ACL Data TX: Handle 64 flags 0x00 dlen 15 #222 [hci0] 19.029554
ATT: Read Response (0x0b) len 10
Value: 31302e302e302e313732
> HCI Event: Number of Completed Packets (0x13) plen 5 #223 [hci0] 19.303772
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #224 [hci0] 19.329773
ATT: Read Request (0x0a) len 2
Handle: 0x00bf
< ACL Data TX: Handle 64 flags 0x00 dlen 18 #225 [hci0] 19.360903
ATT: Read Response (0x0b) len 13
Value: 3235352e3235352e3235352e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #226 [hci0] 19.553228
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #227 [hci0] 19.569694
ATT: Read Request (0x0a) len 2
Handle: 0x00d1
< ACL Data TX: Handle 64 flags 0x00 dlen 13 #228 [hci0] 19.601731
ATT: Read Response (0x0b) len 8
Value: 31302e302e302e31
> HCI Event: Number of Completed Packets (0x13) plen 5 #229 [hci0] 19.803450
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #230 [hci0] 19.809737
ATT: Read Request (0x0a) len 2
Handle: 0x00d5
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #231 [hci0] 19.838368
ATT: Read Response (0x0b) len 7
Value: 302e302e302e30
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #232 [hci0] 20.022517
ATT: Read Request (0x0a) len 2
Handle: 0x00e3
> HCI Event: Number of Completed Packets (0x13) plen 5 #233 [hci0] 20.054753
Num handles: 1
Handle: 64
Count: 1
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #234 [hci0] 20.069675
ATT: Read Response (0x0b) len 4
Value: 74727565
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #235 [hci0] 20.259947
ATT: Read Request (0x0a) len 2
Handle: 0x00d9
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #236 [hci0] 20.300035
ATT: Read Response (0x0b) len 5
Value: 66616c7365
> HCI Event: Number of Completed Packets (0x13) plen 5 #237 [hci0] 20.303077
Num handles: 1
Handle: 64
Count: 1
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #238 [hci0] 20.407493
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #239 [hci0] 20.409871
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #240 [hci0] 20.410110
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #241 [hci0] 20.412256
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #242 [hci0] 20.412479
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #243 [hci0] 20.419311
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #244 [hci0] 20.419542
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #245 [hci0] 20.422861
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #246 [hci0] 20.499675
ATT: Read Request (0x0a) len 2
Handle: 0x00b8
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #247 [hci0] 20.528128
ATT: Read Response (0x0b) len 7
Value: 34303038383539
> HCI Event: Number of Completed Packets (0x13) plen 5 #248 [hci0] 20.553068
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #249 [hci0] 20.747175
ATT: Read Request (0x0a) len 2
Handle: 0x00dc
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #250 [hci0] 20.785261
ATT: Read Response (0x0b) len 5
Value: 3437383038
> HCI Event: Number of Completed Packets (0x13) plen 5 #251 [hci0] 20.803100
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #252 [hci0] 20.979802
ATT: Read Request (0x0a) len 2
Handle: 0x00df
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #253 [hci0] 21.009048
ATT: Read Response (0x0b) len 6
Value: 6e6f726d616c
> HCI Event: Number of Completed Packets (0x13) plen 5 #254 [hci0] 21.053276
Num handles: 1
Handle: 64
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 #255 [hci0] 21.304562
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #256 [hci0] 21.374842
ATT: Read Request (0x0a) len 2
Handle: 0x014a
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #257 [hci0] 21.375975
ATT: Error Response (0x01) len 4
Read Request (0x0a)
Handle: 0x014a
Error: Read Not Permitted (0x02)
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #258 [hci0] 21.579737
ATT: Read Request (0x0a) len 2
Handle: 0x00e6
< ACL Data TX: Handle 64 flags 0x00 dlen 22 #259 [hci0] 21.610337
ATT: Read Response (0x0b) len 17
Value: 68747470733a2f2f6f336875622e636f6d
> HCI Event: Number of Completed Packets (0x13) plen 5 #260 [hci0] 21.670591
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #261 [hci0] 21.819676
ATT: Read Request (0x0a) len 2
Handle: 0x00e6
< ACL Data TX: Handle 64 flags 0x00 dlen 22 #262 [hci0] 21.859144
ATT: Read Response (0x0b) len 17
Value: 68747470733a2f2f6f336875622e636f6d
> HCI Event: Number of Completed Packets (0x13) plen 5 #263 [hci0] 22.053180
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #264 [hci0] 22.209641
ATT: Read Request (0x0a) len 2
Handle: 0x00ff
< ACL Data TX: Handle 64 flags 0x00 dlen 8 #265 [hci0] 22.232801
ATT: Read Response (0x0b) len 3
Value: 302e30
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #266 [hci0] 22.389676
ATT: Read Request (0x0a) len 2
Handle: 0x0057
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #267 [hci0] 22.414704
ATT: Read Response (0x0b) len 5
Value: 3338302e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #268 [hci0] 22.429031
Num handles: 1
Handle: 64
Count: 1
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #269 [hci0] 22.487826
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #270 [hci0] 22.489385
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #271 [hci0] 22.489484
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #272 [hci0] 22.492210
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #273 [hci0] 22.492328
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #274 [hci0] 22.494391
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #275 [hci0] 22.494491
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #276 [hci0] 22.495906
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #277 [hci0] 22.599649
ATT: Read Request (0x0a) len 2
Handle: 0x0106
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #278 [hci0] 22.623811
ATT: Read Response (0x0b) len 2
Value: 3830
> HCI Event: Number of Completed Packets (0x13) plen 5 #279 [hci0] 22.659739
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #280 [hci0] 22.809674
ATT: Read Request (0x0a) len 2
Handle: 0x0109
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #281 [hci0] 22.835913
ATT: Read Response (0x0b) len 2
Value: 3830
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #282 [hci0] 23.019608
ATT: Read Request (0x0a) len 2
Handle: 0x012b
> HCI Event: Number of Completed Packets (0x13) plen 5 #283 [hci0] 23.053263
Num handles: 1
Handle: 64
Count: 1
< ACL Data TX: Handle 64 flags 0x00 dlen 17 #284 [hci0] 23.063725
ATT: Read Response (0x0b) len 12
Value: 303031364134354234463032
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #285 [hci0] 23.259631
ATT: Read Request (0x0a) len 2
Handle: 0x00c9
< ACL Data TX: Handle 64 flags 0x00 dlen 16 #286 [hci0] 23.287984
ATT: Read Response (0x0b) len 11
Value: 3132313431342f30303037
> HCI Event: Number of Completed Packets (0x13) plen 5 #287 [hci0] 23.303214
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #288 [hci0] 23.499636
ATT: Read Request (0x0a) len 2
Handle: 0x0134
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #289 [hci0] 23.522981
ATT: Read Response (0x0b) len 4
Value: 342e3139
> HCI Event: Number of Completed Packets (0x13) plen 5 #290 [hci0] 23.553257
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #291 [hci0] 23.709645
ATT: Read Request (0x0a) len 2
Handle: 0x0131
< ACL Data TX: Handle 64 flags 0x00 dlen 20 #292 [hci0] 23.753698
ATT: Read Response (0x0b) len 15
Value: 322e302e302d616c7068612e313137
> HCI Event: Number of Completed Packets (0x13) plen 5 #293 [hci0] 23.799928
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #294 [hci0] 23.919613
ATT: Read Request (0x0a) len 2
Handle: 0x00ec
< ACL Data TX: Handle 64 flags 0x00 dlen 22 #295 [hci0] 24.099444
ATT: Read Response (0x0b) len 17
Value: 30303a34303a41453a31313a32363a3830
> HCI Event: Number of Completed Packets (0x13) plen 5 #296 [hci0] 24.303300
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #297 [hci0] 24.339622
ATT: Read Request (0x0a) len 2
Handle: 0x00ef
< ACL Data TX: Handle 64 flags 0x00 dlen 22 #298 [hci0] 24.363082
ATT: Read Response (0x0b) len 17
Value: 30303a34303a41453a31313a32363a3831
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #299 [hci0] 24.549614
ATT: Read Request (0x0a) len 2
Handle: 0x012e
> HCI Event: Number of Completed Packets (0x13) plen 5 #300 [hci0] 24.562268
Num handles: 1
Handle: 64
Count: 1
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #301 [hci0] 24.567253
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #302 [hci0] 24.568940
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #303 [hci0] 24.569047
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #304 [hci0] 24.570534
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #305 [hci0] 24.570636
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #306 [hci0] 24.573729
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #307 [hci0] 24.573833
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #308 [hci0] 24.575760
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #309 [hci0] 24.583194
ATT: Read Response (0x0b) len 7
Value: 323031382e3033
> HCI Event: Number of Completed Packets (0x13) plen 5 #310 [hci0] 24.803540
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #311 [hci0] 24.939664
ATT: Read Request (0x0a) len 2
Handle: 0x00f2
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #312 [hci0] 24.969000
ATT: Read Response (0x0b) len 1
Value: 30
> HCI Event: Number of Completed Packets (0x13) plen 5 #313 [hci0] 25.178650
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #314 [hci0] 25.179585
ATT: Read Request (0x0a) len 2
Handle: 0x00f6
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #315 [hci0] 25.212294
ATT: Read Response (0x0b) len 1
Value: 31
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #316 [hci0] 25.420035
ATT: Read Request (0x0a) len 2
Handle: 0x0016
> HCI Event: Number of Completed Packets (0x13) plen 5 #317 [hci0] 25.433343
Num handles: 1
Handle: 64
Count: 1
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #318 [hci0] 25.450144
ATT: Read Response (0x0b) len 5
Value: 32302e3132
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #319 [hci0] 25.629869
ATT: Read Request (0x0a) len 2
Handle: 0x002e
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #320 [hci0] 25.659476
ATT: Read Response (0x0b) len 5
Value: 32302e3032
> HCI Event: Number of Completed Packets (0x13) plen 5 #321 [hci0] 25.679795
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #322 [hci0] 25.869551
ATT: Read Request (0x0a) len 2
Handle: 0x0032
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #323 [hci0] 25.901955
ATT: Read Response (0x0b) len 5
Value: 32302e3639
> HCI Event: Number of Completed Packets (0x13) plen 5 #324 [hci0] 25.928294
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #325 [hci0] 26.109632
ATT: Read Request (0x0a) len 2
Handle: 0x001e
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #326 [hci0] 26.143444
ATT: Read Response (0x0b) len 1
Value: 31
> HCI Event: Number of Completed Packets (0x13) plen 5 #327 [hci0] 26.178570
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #328 [hci0] 26.349544
ATT: Read Request (0x0a) len 2
Handle: 0x002a
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #329 [hci0] 26.385573
ATT: Read Response (0x0b) len 1
Value: 30
> HCI Event: Number of Completed Packets (0x13) plen 5 #330 [hci0] 26.428385
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #331 [hci0] 26.590031
ATT: Read Request (0x0a) len 2
Handle: 0x0115
< ACL Data TX: Handle 64 flags 0x00 dlen 8 #332 [hci0] 26.620533
ATT: Read Response (0x0b) len 3
Value: 333030
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #333 [hci0] 26.647265
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #334 [hci0] 26.648531
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #335 [hci0] 26.648616
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #336 [hci0] 26.649720
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #337 [hci0] 26.649796
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #338 [hci0] 26.657157
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #339 [hci0] 26.657259
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #340 [hci0] 26.658212
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5 #341 [hci0] 26.678308
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #342 [hci0] 26.829510
ATT: Read Request (0x0a) len 2
Handle: 0x001a
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #343 [hci0] 26.859130
ATT: Read Response (0x0b) len 5
Value: 33382e3132
> HCI Event: Number of Completed Packets (0x13) plen 5 #344 [hci0] 26.919658
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #345 [hci0] 27.039807
ATT: Read Request (0x0a) len 2
Handle: 0x0036
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #346 [hci0] 27.082581
ATT: Read Response (0x0b) len 5
Value: 33372e3738
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #347 [hci0] 27.279850
ATT: Read Request (0x0a) len 2
Handle: 0x0022
> HCI Event: Number of Completed Packets (0x13) plen 5 #348 [hci0] 27.303996
Num handles: 1
Handle: 64
Count: 1
< ACL Data TX: Handle 64 flags 0x00 dlen 8 #349 [hci0] 27.310266
ATT: Read Response (0x0b) len 3
Value: 302e30
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #350 [hci0] 27.519495
ATT: Read Request (0x0a) len 2
Handle: 0x003a
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #351 [hci0] 27.551491
ATT: Read Response (0x0b) len 6
Value: 363936302e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #352 [hci0] 27.554811
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #353 [hci0] 27.759488
ATT: Read Request (0x0a) len 2
Handle: 0x0026
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #354 [hci0] 27.798286
ATT: Read Response (0x0b) len 2
Value: 3339
> HCI Event: Number of Completed Packets (0x13) plen 5 #355 [hci0] 27.803954
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #356 [hci0] 27.999533
ATT: Read Request (0x0a) len 2
Handle: 0x0090
< ACL Data TX: Handle 64 flags 0x00 dlen 13 #357 [hci0] 28.030651
ATT: Read Response (0x0b) len 8
Value: 302e303030303030
> HCI Event: Number of Completed Packets (0x13) plen 5 #358 [hci0] 28.053486
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #359 [hci0] 28.239522
ATT: Read Request (0x0a) len 2
Handle: 0x0096
< ACL Data TX: Handle 64 flags 0x00 dlen 13 #360 [hci0] 28.274598
ATT: Read Response (0x0b) len 8
Value: 302e303030303030
> HCI Event: Number of Completed Packets (0x13) plen 5 #361 [hci0] 28.303577
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #362 [hci0] 28.479524
ATT: Read Request (0x0a) len 2
Handle: 0x0080
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #363 [hci0] 28.509526
ATT: Read Response (0x0b) len 1
Value: ff
> HCI Event: Number of Completed Packets (0x13) plen 5 #364 [hci0] 28.554117
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #365 [hci0] 28.720450
ATT: Read Request (0x0a) len 2
Handle: 0x008c
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #366 [hci0] 28.727310
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #367 [hci0] 28.731115
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #368 [hci0] 28.731231
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #369 [hci0] 28.733252
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #370 [hci0] 28.733360
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #371 [hci0] 28.740187
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #372 [hci0] 28.740297
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #373 [hci0] 28.741749
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #374 [hci0] 28.746472
ATT: Read Response (0x0b) len 1
Value: ff
> HCI Event: Number of Completed Packets (0x13) plen 5 #375 [hci0] 28.804858
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #376 [hci0] 28.899514
ATT: Read Request (0x0a) len 2
Handle: 0x0140
< ACL Data TX: Handle 64 flags 0x00 dlen 24 #377 [hci0] 28.900194
ATT: Read Response (0x0b) len 19
Value: 884101f09f9394856720a26047025b9ef90752
> HCI Event: Number of Completed Packets (0x13) plen 5 #378 [hci0] 28.959599
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #379 [hci0] 29.259504
ATT: Read Request (0x0a) len 2
Handle: 0x0102
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #380 [hci0] 29.283236
ATT: Read Response (0x0b) len 5
Value: 32302e3132
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #381 [hci0] 29.469466
ATT: Read Request (0x0a) len 2
Handle: 0x0012
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #382 [hci0] 29.490374
ATT: Read Response (0x0b) len 1
Value: 30
> HCI Event: Number of Completed Packets (0x13) plen 5 #383 [hci0] 29.529557
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #384 [hci0] 29.679497
ATT: Read Request (0x0a) len 2
Handle: 0x00cd
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #385 [hci0] 29.716740
ATT: Read Response (0x0b) len 4
Value: 44484350
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #386 [hci0] 29.800213
ATT: Read Request (0x0a) len 2
Handle: 0x00bb
< ACL Data TX: Handle 64 flags 0x00 dlen 15 #387 [hci0] 29.859780
ATT: Read Response (0x0b) len 10
Value: 31302e302e302e313732
> HCI Event: Number of Completed Packets (0x13) plen 5 #388 [hci0] 29.928665
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #389 [hci0] 29.950396
ATT: Read Request (0x0a) len 2
Handle: 0x00bf
< ACL Data TX: Handle 64 flags 0x00 dlen 18 #390 [hci0] 29.972077
ATT: Read Response (0x0b) len 13
Value: 3235352e3235352e3235352e30
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #391 [hci0] 30.010270
ATT: Read Request (0x0a) len 2
Handle: 0x00d1
> HCI Event: Number of Completed Packets (0x13) plen 5 #392 [hci0] 30.019328
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 13 #393 [hci0] 30.033395
ATT: Read Response (0x0b) len 8
Value: 31302e302e302e31
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #394 [hci0] 30.070249
ATT: Read Request (0x0a) len 2
Handle: 0x00d5
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #395 [hci0] 30.094837
ATT: Read Response (0x0b) len 7
Value: 302e302e302e30
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #396 [hci0] 30.130220
ATT: Read Request (0x0a) len 2
Handle: 0x00e3
> HCI Event: Number of Completed Packets (0x13) plen 5 #397 [hci0] 30.132144
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #398 [hci0] 30.162557
ATT: Read Response (0x0b) len 4
Value: 74727565
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #399 [hci0] 30.220240
ATT: Read Request (0x0a) len 2
Handle: 0x00d9
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #400 [hci0] 30.242132
ATT: Read Response (0x0b) len 5
Value: 66616c7365
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #401 [hci0] 30.280213
ATT: Read Request (0x0a) len 2
Handle: 0x00b8
> HCI Event: Number of Completed Packets (0x13) plen 5 #402 [hci0] 30.283529
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #403 [hci0] 30.315140
ATT: Read Response (0x0b) len 7
Value: 34303038383539
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #404 [hci0] 30.370203
ATT: Read Request (0x0a) len 2
Handle: 0x00dc
< ACL Data TX: Handle 64 flags 0x00 dlen 10 #405 [hci0] 30.426891
ATT: Read Response (0x0b) len 5
Value: 3437383038
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #406 [hci0] 30.490194
ATT: Read Request (0x0a) len 2
Handle: 0x00df
> HCI Event: Number of Completed Packets (0x13) plen 5 #407 [hci0] 30.492565
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #408 [hci0] 30.532733
ATT: Read Response (0x0b) len 6
Value: 6e6f726d616c
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #409 [hci0] 30.580179
ATT: Read Request (0x0a) len 2
Handle: 0x00af
< ACL Data TX: Handle 64 flags 0x00 dlen 6 #410 [hci0] 30.602092
ATT: Read Response (0x0b) len 1
Value: 43
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #411 [hci0] 30.670203
ATT: Read Request (0x0a) len 2
Handle: 0x00b2
> HCI Event: Number of Completed Packets (0x13) plen 5 #412 [hci0] 30.672483
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #413 [hci0] 30.700230
ATT: Read Response (0x0b) len 2
Value: 6c78
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #414 [hci0] 30.807287
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #415 [hci0] 30.808785
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #416 [hci0] 30.808884
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #417 [hci0] 30.811885
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #418 [hci0] 30.812012
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #419 [hci0] 30.815993
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #420 [hci0] 30.816099
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #421 [hci0] 30.816760
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5 #422 [hci0] 30.928652
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #423 [hci0] 31.299915
ATT: Write Request (0x12) len 4
Handle: 0x00ce
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #424 [hci0] 31.300863
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #425 [hci0] 31.360165
ATT: Write Request (0x12) len 4
Handle: 0x00bc
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #426 [hci0] 31.361113
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #427 [hci0] 31.420192
ATT: Write Request (0x12) len 4
Handle: 0x00c0
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #428 [hci0] 31.421200
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #429 [hci0] 31.424830
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #430 [hci0] 31.480148
ATT: Write Request (0x12) len 4
Handle: 0x00d2
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #431 [hci0] 31.481150
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #432 [hci0] 31.540553
ATT: Write Request (0x12) len 4
Handle: 0x00d6
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #433 [hci0] 31.541519
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #434 [hci0] 31.543794
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #435 [hci0] 31.600351
ATT: Write Request (0x12) len 4
Handle: 0x00e0
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #436 [hci0] 31.601866
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #437 [hci0] 31.660339
ATT: Write Request (0x12) len 4
Handle: 0x0017
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #438 [hci0] 31.661402
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #439 [hci0] 31.665367
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #440 [hci0] 31.720194
ATT: Write Request (0x12) len 4
Handle: 0x002f
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #441 [hci0] 31.721135
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #442 [hci0] 31.780550
ATT: Write Request (0x12) len 4
Handle: 0x0033
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #443 [hci0] 31.781551
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #444 [hci0] 31.783791
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #445 [hci0] 31.840182
ATT: Write Request (0x12) len 4
Handle: 0x001f
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #446 [hci0] 31.841122
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #447 [hci0] 31.900146
ATT: Write Request (0x12) len 4
Handle: 0x002b
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #448 [hci0] 31.901170
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #449 [hci0] 31.903365
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #450 [hci0] 31.960469
ATT: Write Request (0x12) len 4
Handle: 0x001b
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #451 [hci0] 31.961472
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #452 [hci0] 32.020170
ATT: Write Request (0x12) len 4
Handle: 0x0037
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #453 [hci0] 32.021174
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #454 [hci0] 32.026170
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #455 [hci0] 32.080199
ATT: Write Request (0x12) len 4
Handle: 0x0023
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #456 [hci0] 32.081194
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #457 [hci0] 32.140336
ATT: Write Request (0x12) len 4
Handle: 0x003b
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #458 [hci0] 32.141372
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #459 [hci0] 32.143945
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #460 [hci0] 32.199840
ATT: Write Request (0x12) len 4
Handle: 0x0027
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #461 [hci0] 32.200847
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #462 [hci0] 32.260148
ATT: Write Request (0x12) len 4
Handle: 0x0081
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #463 [hci0] 32.261153
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #464 [hci0] 32.265317
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #465 [hci0] 32.307308
ATT: Handle Value Notification (0x1b) len 6
Handle: 0x00cd
Data: 44484350
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #466 [hci0] 32.319524
ATT: Write Request (0x12) len 4
Handle: 0x008d
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #467 [hci0] 32.320495
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #468 [hci0] 32.349324
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 17 #469 [hci0] 32.365572
ATT: Handle Value Notification (0x1b) len 12
Handle: 0x00bb
Data: 31302e302e302e313732
> ACL Data RX: Handle 64 flags 0x02 dlen 9 #470 [hci0] 32.379708
ATT: Write Request (0x12) len 4
Handle: 0x0103
Data: 0100
< ACL Data TX: Handle 64 flags 0x00 dlen 5 #471 [hci0] 32.380757
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 #472 [hci0] 32.409356
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 20 #473 [hci0] 32.425882
ATT: Handle Value Notification (0x1b) len 15
Handle: 0x00bf
Data: 3235352e3235352e3235352e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #474 [hci0] 32.469453
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 15 #475 [hci0] 32.485960
ATT: Handle Value Notification (0x1b) len 10
Handle: 0x00d1
Data: 31302e302e302e31
< ACL Data TX: Handle 64 flags 0x00 dlen 14 #476 [hci0] 32.554156
ATT: Handle Value Notification (0x1b) len 9
Handle: 0x00d5
Data: 302e302e302e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #477 [hci0] 32.589431
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 13 #478 [hci0] 32.607254
ATT: Handle Value Notification (0x1b) len 8
Handle: 0x00df
Data: 6e6f726d616c
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #479 [hci0] 32.673240
ATT: Handle Value Notification (0x1b) len 7
Handle: 0x0016
Data: 32302e3132
> HCI Event: Number of Completed Packets (0x13) plen 5 #480 [hci0] 32.709552
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #481 [hci0] 32.728570
ATT: Handle Value Notification (0x1b) len 7
Handle: 0x002e
Data: 32302e3032
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #482 [hci0] 32.786965
ATT: Handle Value Notification (0x1b) len 7
Handle: 0x0032
Data: 32302e3639
> HCI Event: Number of Completed Packets (0x13) plen 5 #483 [hci0] 32.829436
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 8 #484 [hci0] 32.845959
ATT: Handle Value Notification (0x1b) len 3
Handle: 0x001e
Data: 31
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #485 [hci0] 32.887325
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #486 [hci0] 32.889050
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #487 [hci0] 32.889187
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #488 [hci0] 32.892489
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #489 [hci0] 32.892593
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #490 [hci0] 32.898820
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #491 [hci0] 32.898922
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #492 [hci0] 32.900051
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< ACL Data TX: Handle 64 flags 0x00 dlen 8 #493 [hci0] 32.906065
ATT: Handle Value Notification (0x1b) len 3
Handle: 0x002a
Data: 30
> HCI Event: Number of Completed Packets (0x13) plen 5 #494 [hci0] 32.949448
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #495 [hci0] 32.967513
ATT: Handle Value Notification (0x1b) len 7
Handle: 0x001a
Data: 33382e3132
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #496 [hci0] 33.026695
ATT: Handle Value Notification (0x1b) len 7
Handle: 0x0036
Data: 33372e3738
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #497 [hci0] 33.086563
ATT: Handle Value Notification (0x1b) len 6
Handle: 0x0022
Data: 31322e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #498 [hci0] 33.099314
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 13 #499 [hci0] 33.146622
ATT: Handle Value Notification (0x1b) len 8
Handle: 0x003a
Data: 363936302e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #500 [hci0] 33.190184
Num handles: 1
Handle: 64
Count: 2
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #501 [hci0] 33.205824
ATT: Handle Value Notification (0x1b) len 4
Handle: 0x0026
Data: 3339
< ACL Data TX: Handle 64 flags 0x00 dlen 12 #502 [hci0] 33.386084
ATT: Handle Value Notification (0x1b) len 7
Handle: 0x0102
Data: 32302e3132
> HCI Event: Number of Completed Packets (0x13) plen 5 #503 [hci0] 33.429093
Num handles: 1
Handle: 64
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 #504 [hci0] 33.679471
Num handles: 1
Handle: 64
Count: 1
< ACL Data TX: Handle 64 flags 0x00 dlen 13 #505 [hci0] 34.147751
ATT: Handle Value Notification (0x1b) len 8
Handle: 0x003a
Data: 353435382e30
> HCI Event: Number of Completed Packets (0x13) plen 5 #506 [hci0] 34.430344
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 8 #507 [hci0] 34.629385
ATT: Handle Value Notification (0x1b) len 3
Handle: 0x0016
Data: 56
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #508 [hci0] 34.967304
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #509 [hci0] 34.969326
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #510 [hci0] 34.969431
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #511 [hci0] 34.971340
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #512 [hci0] 34.971449
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #513 [hci0] 34.974061
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #514 [hci0] 34.974164
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #515 [hci0] 34.975646
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #516 [hci0] 37.047297
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #517 [hci0] 37.049453
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #518 [hci0] 37.049560
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #519 [hci0] 37.051932
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #520 [hci0] 37.052041
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #521 [hci0] 37.057000
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #522 [hci0] 37.057220
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #523 [hci0] 37.058216
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #524 [hci0] 39.127281
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #525 [hci0] 39.128857
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #526 [hci0] 39.128951
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #527 [hci0] 39.130785
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #528 [hci0] 39.130881
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #529 [hci0] 39.133950
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #530 [hci0] 39.134048
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #531 [hci0] 39.135240
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #532 [hci0] 41.207548
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #533 [hci0] 41.209057
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #534 [hci0] 41.209158
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #535 [hci0] 41.212789
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #536 [hci0] 41.212903
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #537 [hci0] 41.213871
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #538 [hci0] 41.213963
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #539 [hci0] 41.214978
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #540 [hci0] 43.287292
Length: 29
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 00005c8e6b8bf66a4ab7a3590016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #541 [hci0] 43.288771
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #542 [hci0] 43.288870
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #543 [hci0] 43.290069
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #544 [hci0] 43.290170
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #545 [hci0] 43.293277
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #546 [hci0] 43.293385
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #547 [hci0] 43.294794
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 #548 [hci0] 44.214349
ATT: Handle Value Notification (0x1b) len 4
Handle: 0x0026
Data: 3434
> HCI Event: Number of Completed Packets (0x13) plen 5 #549 [hci0] 44.430583
Num handles: 1
Handle: 64
Count: 1
< HCI Command: LE Set Advertisin.. (0x08|0x0008) plen 32 #550 [hci0] 45.367178
Length: 17
Flags: 0x02
LE General Discoverable Mode
16-bit Service UUIDs (complete): 1 entry
Unknown (0x4822)
Company: not assigned (1694)
Data: 0016a45b4f02
> HCI Event: Command Complete (0x0e) plen 4 #551 [hci0] 45.368614
LE Set Advertising Data (0x08|0x0008) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1 #552 [hci0] 45.368700
Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #553 [hci0] 45.370622
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15 #554 [hci0] 45.370705
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-13 5:59 Disabled bluetooth cache. But the app still getting wrong data? Kenny Bian
@ 2021-04-13 6:39 ` Jamie Mccrae
2021-04-13 17:17 ` Kenny Bian
2021-04-13 21:57 ` Luiz Augusto von Dentz
0 siblings, 2 replies; 13+ messages in thread
From: Jamie Mccrae @ 2021-04-13 6:39 UTC (permalink / raw)
To: Kenny Bian, linux-bluetooth
Hi Kenny,
Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
Thanks,
Jamie
-----Original Message-----
From: Kenny Bian <kennybian@gmail.com>
Sent: 13 April 2021 06:59
To: linux-bluetooth@vger.kernel.org
Subject: Disabled bluetooth cache. But the app still getting wrong data?
EXTERNAL EMAIL: Be careful with attachments and links.
Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
In order to keep the pairing information, the "/var/lib/bluetooth"
folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
"/etc/bluetooth/main.conf":
[GATT]
Cache = no
But recently, we saw the problem again even if the bluetooth cache is
disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
Questions:
1. How is it possible that this still happens even if the bluetooth cache is disabled?
2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
3. Is there anything else we should look into?
We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
Thanks!
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-13 6:39 ` Jamie Mccrae
@ 2021-04-13 17:17 ` Kenny Bian
2021-04-13 21:57 ` Luiz Augusto von Dentz
1 sibling, 0 replies; 13+ messages in thread
From: Kenny Bian @ 2021-04-13 17:17 UTC (permalink / raw)
To: Jamie Mccrae; +Cc: linux-bluetooth
Hi Jamie,
Thank you for your email. Do you know how to add "Service Changed
Indication"? We would like to support that. But we don't know how to
do it.
In fact, I posted the question before:
https://www.spinics.net/lists/linux-bluetooth/msg89959.html. It seems
"If you are registering the services with Bluetoothd then it should
generate the service change". Our GATT server is based on
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server.
By saying "registering the services", does it mean our code should
call "RegisterApplication()"? We did call RegisterApplication(). But
we never saw the "[ServiceChanged]"
section(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/settings-storage.txt#n321).
Please let us know if you know how to add "Service Changed
Indication".
Thanks!
Kenny
Kenny
On Mon, Apr 12, 2021 at 11:39 PM Jamie Mccrae
<Jamie.Mccrae@lairdconnect.com> wrote:
>
> Hi Kenny,
> Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> Thanks,
> Jamie
>
> -----Original Message-----
> From: Kenny Bian <kennybian@gmail.com>
> Sent: 13 April 2021 06:59
> To: linux-bluetooth@vger.kernel.org
> Subject: Disabled bluetooth cache. But the app still getting wrong data?
>
> EXTERNAL EMAIL: Be careful with attachments and links.
>
> Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> In order to keep the pairing information, the "/var/lib/bluetooth"
> folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> "/etc/bluetooth/main.conf":
> [GATT]
> Cache = no
>
> But recently, we saw the problem again even if the bluetooth cache is
> disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
>
> The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
>
> I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
>
> Questions:
> 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> 3. Is there anything else we should look into?
>
> We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
>
> Thanks!
> THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-13 6:39 ` Jamie Mccrae
2021-04-13 17:17 ` Kenny Bian
@ 2021-04-13 21:57 ` Luiz Augusto von Dentz
2021-04-14 4:46 ` Kenny Bian
1 sibling, 1 reply; 13+ messages in thread
From: Luiz Augusto von Dentz @ 2021-04-13 21:57 UTC (permalink / raw)
To: Jamie Mccrae; +Cc: Kenny Bian, linux-bluetooth
Hi Jamie, Brian,
On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
<Jamie.Mccrae@lairdconnect.com> wrote:
>
> Hi Kenny,
> Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
Yep, and while at it implement the so called Robust Caching feature so
we can detect if anything has changed by reading the DB Hash.
> Thanks,
> Jamie
>
> -----Original Message-----
> From: Kenny Bian <kennybian@gmail.com>
> Sent: 13 April 2021 06:59
> To: linux-bluetooth@vger.kernel.org
> Subject: Disabled bluetooth cache. But the app still getting wrong data?
>
> EXTERNAL EMAIL: Be careful with attachments and links.
>
> Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> In order to keep the pairing information, the "/var/lib/bluetooth"
> folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> "/etc/bluetooth/main.conf":
> [GATT]
> Cache = no
When you say the app can't handle changed service do you mean BlueZ
doesn't emit changes to the attributes (via Service Changed) or is it
really the application not being able to handle the changes?
> But recently, we saw the problem again even if the bluetooth cache is
> disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
So BlueZ is acting as the server, right? The Cache only applies to the
client portion, there is no such thing as disabling the remote cache.
I don't see any incoming Read By Group Request from the remote so it
is very likely that it has cached the values, there is no Read By Type
for the DB Hash either which is quite surprising to me since that is
required for stacks supporting Robust Caching which I believe is the
case of iOS.
Anyway, I would check that the following lines are being triggered:
When starting:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
On connect:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
If those lines are not being triggered it is likely a client problem
which for some reason had not subscribed to received service changes
for some reason, if it doesn't subscribe to service changes then it
shall not cache any attribute and attempt to rediscover on every
connection.
> The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
>
> I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
>
> Questions:
> 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> 3. Is there anything else we should look into?
>
> We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
>
> Thanks!
> THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-13 21:57 ` Luiz Augusto von Dentz
@ 2021-04-14 4:46 ` Kenny Bian
2021-04-15 5:44 ` Kenny Bian
0 siblings, 1 reply; 13+ messages in thread
From: Kenny Bian @ 2021-04-14 4:46 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Jamie Mccrae, linux-bluetooth
Hi Jamie, Luiz,
Thanks for your info.
Luiz, to answer your questions:
BlueZ doesn't seem to emit "Service Changed Indication". Or it does
emit it, but we don't know how to verify it.
Yes, BlueZ acts as a GATT server which runs on Linux.
So my questions:
How can I tell if "Service Changed Indication" is working? I need to
show it to our app developers that the GATT server does send the
"Service Changed Indication" when there is a service change.
By disabling the GATT's cache in "/etc/bluetooth/main.conf", the
"Service Changed Indication" is disabled?
Can "Service Changed Indication" be enabled in a conf file? Or should
it be done in the Python code? Could you please help find out that
info?
Our GATT server is based on the Python code
examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
I don't know how to enable "Service Changed Indication" or "Robust
Caching" in Python code on the GATT server side. There is no document
or code samples about that. Please let me know if there is any
document or Python code example.
Thanks!
Kenny
On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Jamie, Brian,
>
> On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> <Jamie.Mccrae@lairdconnect.com> wrote:
> >
> > Hi Kenny,
> > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
>
> Yep, and while at it implement the so called Robust Caching feature so
> we can detect if anything has changed by reading the DB Hash.
>
> > Thanks,
> > Jamie
> >
> > -----Original Message-----
> > From: Kenny Bian <kennybian@gmail.com>
> > Sent: 13 April 2021 06:59
> > To: linux-bluetooth@vger.kernel.org
> > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> >
> > EXTERNAL EMAIL: Be careful with attachments and links.
> >
> > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > In order to keep the pairing information, the "/var/lib/bluetooth"
> > folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> > "/etc/bluetooth/main.conf":
> > [GATT]
> > Cache = no
>
> When you say the app can't handle changed service do you mean BlueZ
> doesn't emit changes to the attributes (via Service Changed) or is it
> really the application not being able to handle the changes?
>
> > But recently, we saw the problem again even if the bluetooth cache is
> > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
>
> So BlueZ is acting as the server, right? The Cache only applies to the
> client portion, there is no such thing as disabling the remote cache.
> I don't see any incoming Read By Group Request from the remote so it
> is very likely that it has cached the values, there is no Read By Type
> for the DB Hash either which is quite surprising to me since that is
> required for stacks supporting Robust Caching which I believe is the
> case of iOS.
>
> Anyway, I would check that the following lines are being triggered:
>
> When starting:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
>
> On connect:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
>
> If those lines are not being triggered it is likely a client problem
> which for some reason had not subscribed to received service changes
> for some reason, if it doesn't subscribe to service changes then it
> shall not cache any attribute and attempt to rediscover on every
> connection.
>
> > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> >
> > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> >
> > Questions:
> > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > 3. Is there anything else we should look into?
> >
> > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> >
> > Thanks!
> > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
>
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-14 4:46 ` Kenny Bian
@ 2021-04-15 5:44 ` Kenny Bian
2021-04-15 20:31 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 13+ messages in thread
From: Kenny Bian @ 2021-04-15 5:44 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Jamie Mccrae, linux-bluetooth
Hi Luiz,
There is a UI example of nRF Connect which shows the "Service Changed
Indication" is under "Generic
Attribute"(http://forum.espruino.com/conversations/357737/). We're
using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
class ServiceChangedChrc(Characteristic):
SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
def __init__(self, bus, index, service):
Characteristic.__init__(
self, bus, index,
self.SCI_UUID,
['indicate'],
service)
def IndicateValue(self, options):
# This function doesn't exist. Just list it here.
pass
class ServiceChangedService(Service):
MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
def __init__(self, bus, index):
Service.__init__(self, bus, index, self.MY_UUID, True)
self.add_characteristic(ServiceChangedChrc(bus, 0, self))
class Application(dbus.service.Object):
"""
org.bluez.GattApplication1 interface implementation
"""
def __init__(self, bus):
self.path = '/'
self.services = []
dbus.service.Object.__init__(self, bus, self.path)
self.add_service(HeartRateService(bus, 0))
self.add_service(BatteryService(bus, 1))
self.add_service(TestService(bus, 2))
self.add_service(ServiceChangedService(bus, 3))
When I run it, there is "Failed to register application:
org.bluez.Error.Failed: Failed to create entry in database". That is
in the function client_ready_cb() in gatt-database.c in BlueZ code. Do
you know how to fix it?
Thanks!
Kenny
On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
>
> Hi Jamie, Luiz,
>
> Thanks for your info.
>
> Luiz, to answer your questions:
> BlueZ doesn't seem to emit "Service Changed Indication". Or it does
> emit it, but we don't know how to verify it.
> Yes, BlueZ acts as a GATT server which runs on Linux.
>
> So my questions:
> How can I tell if "Service Changed Indication" is working? I need to
> show it to our app developers that the GATT server does send the
> "Service Changed Indication" when there is a service change.
> By disabling the GATT's cache in "/etc/bluetooth/main.conf", the
> "Service Changed Indication" is disabled?
> Can "Service Changed Indication" be enabled in a conf file? Or should
> it be done in the Python code? Could you please help find out that
> info?
> Our GATT server is based on the Python code
> examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> I don't know how to enable "Service Changed Indication" or "Robust
> Caching" in Python code on the GATT server side. There is no document
> or code samples about that. Please let me know if there is any
> document or Python code example.
>
> Thanks!
> Kenny
>
> On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Jamie, Brian,
> >
> > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > <Jamie.Mccrae@lairdconnect.com> wrote:
> > >
> > > Hi Kenny,
> > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> >
> > Yep, and while at it implement the so called Robust Caching feature so
> > we can detect if anything has changed by reading the DB Hash.
> >
> > > Thanks,
> > > Jamie
> > >
> > > -----Original Message-----
> > > From: Kenny Bian <kennybian@gmail.com>
> > > Sent: 13 April 2021 06:59
> > > To: linux-bluetooth@vger.kernel.org
> > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > >
> > > EXTERNAL EMAIL: Be careful with attachments and links.
> > >
> > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> > > "/etc/bluetooth/main.conf":
> > > [GATT]
> > > Cache = no
> >
> > When you say the app can't handle changed service do you mean BlueZ
> > doesn't emit changes to the attributes (via Service Changed) or is it
> > really the application not being able to handle the changes?
> >
> > > But recently, we saw the problem again even if the bluetooth cache is
> > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> >
> > So BlueZ is acting as the server, right? The Cache only applies to the
> > client portion, there is no such thing as disabling the remote cache.
> > I don't see any incoming Read By Group Request from the remote so it
> > is very likely that it has cached the values, there is no Read By Type
> > for the DB Hash either which is quite surprising to me since that is
> > required for stacks supporting Robust Caching which I believe is the
> > case of iOS.
> >
> > Anyway, I would check that the following lines are being triggered:
> >
> > When starting:
> >
> > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
> >
> > On connect:
> >
> > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
> >
> > If those lines are not being triggered it is likely a client problem
> > which for some reason had not subscribed to received service changes
> > for some reason, if it doesn't subscribe to service changes then it
> > shall not cache any attribute and attempt to rediscover on every
> > connection.
> >
> > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > >
> > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > >
> > > Questions:
> > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > 3. Is there anything else we should look into?
> > >
> > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > >
> > > Thanks!
> > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> >
> >
> >
> > --
> > Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-15 5:44 ` Kenny Bian
@ 2021-04-15 20:31 ` Luiz Augusto von Dentz
2021-04-16 0:20 ` Kenny Bian
0 siblings, 1 reply; 13+ messages in thread
From: Luiz Augusto von Dentz @ 2021-04-15 20:31 UTC (permalink / raw)
To: Kenny Bian; +Cc: Jamie Mccrae, linux-bluetooth
Hi Kenny,
On Wed, Apr 14, 2021 at 10:44 PM Kenny Bian <kennybian@gmail.com> wrote:
>
> Hi Luiz,
>
> There is a UI example of nRF Connect which shows the "Service Changed
> Indication" is under "Generic
> Attribute"(http://forum.espruino.com/conversations/357737/). We're
> using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
You should have mentioned that you are using 5.48, you need the following patch:
commit a0b886e26c83ad4dfbf0b2b2e024c8ce9ead9a7d
Author: Szymon Janc <szymon.janc@codecoup.pl>
Date: Wed Mar 28 12:10:55 2018 +0200
gatt: Add support for storing Service Changed CCC value
This adds support for storing CCC value of Service Changed
characteristic. Once bluetoothd is restart stored values are read
and any device subscribed to indications will receive Service Changed
indication with 0x00010-0xffff value. This is to invalidate any
non-core services since there is no way to verify if applications
will register their services in same order (or at all).
This fix accessing invalid handles by stacks that rely only on Service
Changed indication for rediscovery ie. Apple iOS.
Or upgrade to a BlueZ release that has the above patch, which should be 5.50:
+ver 5.50:
+ Fix issue with GATT and reading long values.
+ Fix issue with GATT and reading multiple includes.
+ Fix issue with GATT and service changes when offline.
+ Fix issue with handling secondary service discovery.
+ Fix issue with handling persistency of CCC values.
>
> class ServiceChangedChrc(Characteristic):
> SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
>
> def __init__(self, bus, index, service):
> Characteristic.__init__(
> self, bus, index,
> self.SCI_UUID,
> ['indicate'],
> service)
>
> def IndicateValue(self, options):
> # This function doesn't exist. Just list it here.
> pass
>
>
> class ServiceChangedService(Service):
> MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
>
> def __init__(self, bus, index):
> Service.__init__(self, bus, index, self.MY_UUID, True)
> self.add_characteristic(ServiceChangedChrc(bus, 0, self))
>
>
> class Application(dbus.service.Object):
> """
> org.bluez.GattApplication1 interface implementation
> """
> def __init__(self, bus):
> self.path = '/'
> self.services = []
> dbus.service.Object.__init__(self, bus, self.path)
> self.add_service(HeartRateService(bus, 0))
> self.add_service(BatteryService(bus, 1))
> self.add_service(TestService(bus, 2))
> self.add_service(ServiceChangedService(bus, 3))
>
>
> When I run it, there is "Failed to register application:
> org.bluez.Error.Failed: Failed to create entry in database". That is
> in the function client_ready_cb() in gatt-database.c in BlueZ code. Do
> you know how to fix it?
You don't need to register Service Changed, the daemon already takes
care of registering it and there could only be one Service Changed in
the database.
> Thanks!
> Kenny
>
> On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
> >
> > Hi Jamie, Luiz,
> >
> > Thanks for your info.
> >
> > Luiz, to answer your questions:
> > BlueZ doesn't seem to emit "Service Changed Indication". Or it does
> > emit it, but we don't know how to verify it.
> > Yes, BlueZ acts as a GATT server which runs on Linux.
> >
> > So my questions:
> > How can I tell if "Service Changed Indication" is working? I need to
> > show it to our app developers that the GATT server does send the
> > "Service Changed Indication" when there is a service change.
> > By disabling the GATT's cache in "/etc/bluetooth/main.conf", the
> > "Service Changed Indication" is disabled?
> > Can "Service Changed Indication" be enabled in a conf file? Or should
> > it be done in the Python code? Could you please help find out that
> > info?
> > Our GATT server is based on the Python code
> > examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> > I don't know how to enable "Service Changed Indication" or "Robust
> > Caching" in Python code on the GATT server side. There is no document
> > or code samples about that. Please let me know if there is any
> > document or Python code example.
> >
> > Thanks!
> > Kenny
> >
> > On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> wrote:
> > >
> > > Hi Jamie, Brian,
> > >
> > > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > > <Jamie.Mccrae@lairdconnect.com> wrote:
> > > >
> > > > Hi Kenny,
> > > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> > >
> > > Yep, and while at it implement the so called Robust Caching feature so
> > > we can detect if anything has changed by reading the DB Hash.
> > >
> > > > Thanks,
> > > > Jamie
> > > >
> > > > -----Original Message-----
> > > > From: Kenny Bian <kennybian@gmail.com>
> > > > Sent: 13 April 2021 06:59
> > > > To: linux-bluetooth@vger.kernel.org
> > > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > > >
> > > > EXTERNAL EMAIL: Be careful with attachments and links.
> > > >
> > > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > > folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> > > > "/etc/bluetooth/main.conf":
> > > > [GATT]
> > > > Cache = no
> > >
> > > When you say the app can't handle changed service do you mean BlueZ
> > > doesn't emit changes to the attributes (via Service Changed) or is it
> > > really the application not being able to handle the changes?
> > >
> > > > But recently, we saw the problem again even if the bluetooth cache is
> > > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> > >
> > > So BlueZ is acting as the server, right? The Cache only applies to the
> > > client portion, there is no such thing as disabling the remote cache.
> > > I don't see any incoming Read By Group Request from the remote so it
> > > is very likely that it has cached the values, there is no Read By Type
> > > for the DB Hash either which is quite surprising to me since that is
> > > required for stacks supporting Robust Caching which I believe is the
> > > case of iOS.
> > >
> > > Anyway, I would check that the following lines are being triggered:
> > >
> > > When starting:
> > >
> > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
> > >
> > > On connect:
> > >
> > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
> > >
> > > If those lines are not being triggered it is likely a client problem
> > > which for some reason had not subscribed to received service changes
> > > for some reason, if it doesn't subscribe to service changes then it
> > > shall not cache any attribute and attempt to rediscover on every
> > > connection.
> > >
> > > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > > >
> > > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > > >
> > > > Questions:
> > > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > > 3. Is there anything else we should look into?
> > > >
> > > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > > >
> > > > Thanks!
> > > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> > >
> > >
> > >
> > > --
> > > Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-15 20:31 ` Luiz Augusto von Dentz
@ 2021-04-16 0:20 ` Kenny Bian
2021-04-16 0:49 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 13+ messages in thread
From: Kenny Bian @ 2021-04-16 0:20 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Jamie Mccrae, linux-bluetooth
Hi Luiz,
Thank you so much. I appreciate it.
That was my bad. I just checked. Our system is Ubuntu 18.04. The BlueZ
version is "5.48-0ubuntu3.4" which is different from the versions in
http://www.bluez.org/. I'm trying to figure out if this version
includes the version 5.50. Do you know the corresponding BlueZ version
for "5.48-0ubuntu3.4"?
Thanks!
Kenny
On Thu, Apr 15, 2021 at 1:31 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Kenny,
>
> On Wed, Apr 14, 2021 at 10:44 PM Kenny Bian <kennybian@gmail.com> wrote:
> >
> > Hi Luiz,
> >
> > There is a UI example of nRF Connect which shows the "Service Changed
> > Indication" is under "Generic
> > Attribute"(http://forum.espruino.com/conversations/357737/). We're
> > using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
>
>
> You should have mentioned that you are using 5.48, you need the following patch:
>
> commit a0b886e26c83ad4dfbf0b2b2e024c8ce9ead9a7d
> Author: Szymon Janc <szymon.janc@codecoup.pl>
> Date: Wed Mar 28 12:10:55 2018 +0200
>
> gatt: Add support for storing Service Changed CCC value
>
> This adds support for storing CCC value of Service Changed
> characteristic. Once bluetoothd is restart stored values are read
> and any device subscribed to indications will receive Service Changed
> indication with 0x00010-0xffff value. This is to invalidate any
> non-core services since there is no way to verify if applications
> will register their services in same order (or at all).
>
> This fix accessing invalid handles by stacks that rely only on Service
> Changed indication for rediscovery ie. Apple iOS.
>
> Or upgrade to a BlueZ release that has the above patch, which should be 5.50:
>
> +ver 5.50:
> + Fix issue with GATT and reading long values.
> + Fix issue with GATT and reading multiple includes.
> + Fix issue with GATT and service changes when offline.
> + Fix issue with handling secondary service discovery.
> + Fix issue with handling persistency of CCC values.
>
> >
> > class ServiceChangedChrc(Characteristic):
> > SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
> >
> > def __init__(self, bus, index, service):
> > Characteristic.__init__(
> > self, bus, index,
> > self.SCI_UUID,
> > ['indicate'],
> > service)
> >
> > def IndicateValue(self, options):
> > # This function doesn't exist. Just list it here.
> > pass
> >
> >
> > class ServiceChangedService(Service):
> > MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
> >
> > def __init__(self, bus, index):
> > Service.__init__(self, bus, index, self.MY_UUID, True)
> > self.add_characteristic(ServiceChangedChrc(bus, 0, self))
> >
> >
> > class Application(dbus.service.Object):
> > """
> > org.bluez.GattApplication1 interface implementation
> > """
> > def __init__(self, bus):
> > self.path = '/'
> > self.services = []
> > dbus.service.Object.__init__(self, bus, self.path)
> > self.add_service(HeartRateService(bus, 0))
> > self.add_service(BatteryService(bus, 1))
> > self.add_service(TestService(bus, 2))
> > self.add_service(ServiceChangedService(bus, 3))
> >
> >
> > When I run it, there is "Failed to register application:
> > org.bluez.Error.Failed: Failed to create entry in database". That is
> > in the function client_ready_cb() in gatt-database.c in BlueZ code. Do
> > you know how to fix it?
>
> You don't need to register Service Changed, the daemon already takes
> care of registering it and there could only be one Service Changed in
> the database.
>
> > Thanks!
> > Kenny
> >
> > On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
> > >
> > > Hi Jamie, Luiz,
> > >
> > > Thanks for your info.
> > >
> > > Luiz, to answer your questions:
> > > BlueZ doesn't seem to emit "Service Changed Indication". Or it does
> > > emit it, but we don't know how to verify it.
> > > Yes, BlueZ acts as a GATT server which runs on Linux.
> > >
> > > So my questions:
> > > How can I tell if "Service Changed Indication" is working? I need to
> > > show it to our app developers that the GATT server does send the
> > > "Service Changed Indication" when there is a service change.
> > > By disabling the GATT's cache in "/etc/bluetooth/main.conf", the
> > > "Service Changed Indication" is disabled?
> > > Can "Service Changed Indication" be enabled in a conf file? Or should
> > > it be done in the Python code? Could you please help find out that
> > > info?
> > > Our GATT server is based on the Python code
> > > examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> > > I don't know how to enable "Service Changed Indication" or "Robust
> > > Caching" in Python code on the GATT server side. There is no document
> > > or code samples about that. Please let me know if there is any
> > > document or Python code example.
> > >
> > > Thanks!
> > > Kenny
> > >
> > > On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> > > <luiz.dentz@gmail.com> wrote:
> > > >
> > > > Hi Jamie, Brian,
> > > >
> > > > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > > > <Jamie.Mccrae@lairdconnect.com> wrote:
> > > > >
> > > > > Hi Kenny,
> > > > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> > > >
> > > > Yep, and while at it implement the so called Robust Caching feature so
> > > > we can detect if anything has changed by reading the DB Hash.
> > > >
> > > > > Thanks,
> > > > > Jamie
> > > > >
> > > > > -----Original Message-----
> > > > > From: Kenny Bian <kennybian@gmail.com>
> > > > > Sent: 13 April 2021 06:59
> > > > > To: linux-bluetooth@vger.kernel.org
> > > > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > > > >
> > > > > EXTERNAL EMAIL: Be careful with attachments and links.
> > > > >
> > > > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > > > folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> > > > > "/etc/bluetooth/main.conf":
> > > > > [GATT]
> > > > > Cache = no
> > > >
> > > > When you say the app can't handle changed service do you mean BlueZ
> > > > doesn't emit changes to the attributes (via Service Changed) or is it
> > > > really the application not being able to handle the changes?
> > > >
> > > > > But recently, we saw the problem again even if the bluetooth cache is
> > > > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> > > >
> > > > So BlueZ is acting as the server, right? The Cache only applies to the
> > > > client portion, there is no such thing as disabling the remote cache.
> > > > I don't see any incoming Read By Group Request from the remote so it
> > > > is very likely that it has cached the values, there is no Read By Type
> > > > for the DB Hash either which is quite surprising to me since that is
> > > > required for stacks supporting Robust Caching which I believe is the
> > > > case of iOS.
> > > >
> > > > Anyway, I would check that the following lines are being triggered:
> > > >
> > > > When starting:
> > > >
> > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
> > > >
> > > > On connect:
> > > >
> > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
> > > >
> > > > If those lines are not being triggered it is likely a client problem
> > > > which for some reason had not subscribed to received service changes
> > > > for some reason, if it doesn't subscribe to service changes then it
> > > > shall not cache any attribute and attempt to rediscover on every
> > > > connection.
> > > >
> > > > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > > > >
> > > > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > > > >
> > > > > Questions:
> > > > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > > > 3. Is there anything else we should look into?
> > > > >
> > > > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > > > >
> > > > > Thanks!
> > > > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> > > >
> > > >
> > > >
> > > > --
> > > > Luiz Augusto von Dentz
>
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-16 0:20 ` Kenny Bian
@ 2021-04-16 0:49 ` Luiz Augusto von Dentz
2021-04-16 3:06 ` Kenny Bian
0 siblings, 1 reply; 13+ messages in thread
From: Luiz Augusto von Dentz @ 2021-04-16 0:49 UTC (permalink / raw)
To: Kenny Bian; +Cc: Jamie Mccrae, linux-bluetooth
Hi Kenny,
On Thu, Apr 15, 2021 at 5:21 PM Kenny Bian <kennybian@gmail.com> wrote:
>
> Hi Luiz,
>
> Thank you so much. I appreciate it.
>
> That was my bad. I just checked. Our system is Ubuntu 18.04. The BlueZ
> version is "5.48-0ubuntu3.4" which is different from the versions in
> http://www.bluez.org/. I'm trying to figure out if this version
> includes the version 5.50. Do you know the corresponding BlueZ version
> for "5.48-0ubuntu3.4"?
5.48, which was the version available in 2018, more than 3 years/10
releases ago, a lot of things have been fixed over this time so Id
really recommend to upgrade to the latest if you want to have some
support.
> Thanks!
> Kenny
>
> On Thu, Apr 15, 2021 at 1:31 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Kenny,
> >
> > On Wed, Apr 14, 2021 at 10:44 PM Kenny Bian <kennybian@gmail.com> wrote:
> > >
> > > Hi Luiz,
> > >
> > > There is a UI example of nRF Connect which shows the "Service Changed
> > > Indication" is under "Generic
> > > Attribute"(http://forum.espruino.com/conversations/357737/). We're
> > > using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
> >
> >
> > You should have mentioned that you are using 5.48, you need the following patch:
> >
> > commit a0b886e26c83ad4dfbf0b2b2e024c8ce9ead9a7d
> > Author: Szymon Janc <szymon.janc@codecoup.pl>
> > Date: Wed Mar 28 12:10:55 2018 +0200
> >
> > gatt: Add support for storing Service Changed CCC value
> >
> > This adds support for storing CCC value of Service Changed
> > characteristic. Once bluetoothd is restart stored values are read
> > and any device subscribed to indications will receive Service Changed
> > indication with 0x00010-0xffff value. This is to invalidate any
> > non-core services since there is no way to verify if applications
> > will register their services in same order (or at all).
> >
> > This fix accessing invalid handles by stacks that rely only on Service
> > Changed indication for rediscovery ie. Apple iOS.
> >
> > Or upgrade to a BlueZ release that has the above patch, which should be 5.50:
> >
> > +ver 5.50:
> > + Fix issue with GATT and reading long values.
> > + Fix issue with GATT and reading multiple includes.
> > + Fix issue with GATT and service changes when offline.
> > + Fix issue with handling secondary service discovery.
> > + Fix issue with handling persistency of CCC values.
> >
> > >
> > > class ServiceChangedChrc(Characteristic):
> > > SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
> > >
> > > def __init__(self, bus, index, service):
> > > Characteristic.__init__(
> > > self, bus, index,
> > > self.SCI_UUID,
> > > ['indicate'],
> > > service)
> > >
> > > def IndicateValue(self, options):
> > > # This function doesn't exist. Just list it here.
> > > pass
> > >
> > >
> > > class ServiceChangedService(Service):
> > > MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
> > >
> > > def __init__(self, bus, index):
> > > Service.__init__(self, bus, index, self.MY_UUID, True)
> > > self.add_characteristic(ServiceChangedChrc(bus, 0, self))
> > >
> > >
> > > class Application(dbus.service.Object):
> > > """
> > > org.bluez.GattApplication1 interface implementation
> > > """
> > > def __init__(self, bus):
> > > self.path = '/'
> > > self.services = []
> > > dbus.service.Object.__init__(self, bus, self.path)
> > > self.add_service(HeartRateService(bus, 0))
> > > self.add_service(BatteryService(bus, 1))
> > > self.add_service(TestService(bus, 2))
> > > self.add_service(ServiceChangedService(bus, 3))
> > >
> > >
> > > When I run it, there is "Failed to register application:
> > > org.bluez.Error.Failed: Failed to create entry in database". That is
> > > in the function client_ready_cb() in gatt-database.c in BlueZ code. Do
> > > you know how to fix it?
> >
> > You don't need to register Service Changed, the daemon already takes
> > care of registering it and there could only be one Service Changed in
> > the database.
> >
> > > Thanks!
> > > Kenny
> > >
> > > On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > >
> > > > Hi Jamie, Luiz,
> > > >
> > > > Thanks for your info.
> > > >
> > > > Luiz, to answer your questions:
> > > > BlueZ doesn't seem to emit "Service Changed Indication". Or it does
> > > > emit it, but we don't know how to verify it.
> > > > Yes, BlueZ acts as a GATT server which runs on Linux.
> > > >
> > > > So my questions:
> > > > How can I tell if "Service Changed Indication" is working? I need to
> > > > show it to our app developers that the GATT server does send the
> > > > "Service Changed Indication" when there is a service change.
> > > > By disabling the GATT's cache in "/etc/bluetooth/main.conf", the
> > > > "Service Changed Indication" is disabled?
> > > > Can "Service Changed Indication" be enabled in a conf file? Or should
> > > > it be done in the Python code? Could you please help find out that
> > > > info?
> > > > Our GATT server is based on the Python code
> > > > examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> > > > I don't know how to enable "Service Changed Indication" or "Robust
> > > > Caching" in Python code on the GATT server side. There is no document
> > > > or code samples about that. Please let me know if there is any
> > > > document or Python code example.
> > > >
> > > > Thanks!
> > > > Kenny
> > > >
> > > > On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> > > > <luiz.dentz@gmail.com> wrote:
> > > > >
> > > > > Hi Jamie, Brian,
> > > > >
> > > > > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > > > > <Jamie.Mccrae@lairdconnect.com> wrote:
> > > > > >
> > > > > > Hi Kenny,
> > > > > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> > > > >
> > > > > Yep, and while at it implement the so called Robust Caching feature so
> > > > > we can detect if anything has changed by reading the DB Hash.
> > > > >
> > > > > > Thanks,
> > > > > > Jamie
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Kenny Bian <kennybian@gmail.com>
> > > > > > Sent: 13 April 2021 06:59
> > > > > > To: linux-bluetooth@vger.kernel.org
> > > > > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > > > > >
> > > > > > EXTERNAL EMAIL: Be careful with attachments and links.
> > > > > >
> > > > > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > > > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > > > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > > > > folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> > > > > > "/etc/bluetooth/main.conf":
> > > > > > [GATT]
> > > > > > Cache = no
> > > > >
> > > > > When you say the app can't handle changed service do you mean BlueZ
> > > > > doesn't emit changes to the attributes (via Service Changed) or is it
> > > > > really the application not being able to handle the changes?
> > > > >
> > > > > > But recently, we saw the problem again even if the bluetooth cache is
> > > > > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> > > > >
> > > > > So BlueZ is acting as the server, right? The Cache only applies to the
> > > > > client portion, there is no such thing as disabling the remote cache.
> > > > > I don't see any incoming Read By Group Request from the remote so it
> > > > > is very likely that it has cached the values, there is no Read By Type
> > > > > for the DB Hash either which is quite surprising to me since that is
> > > > > required for stacks supporting Robust Caching which I believe is the
> > > > > case of iOS.
> > > > >
> > > > > Anyway, I would check that the following lines are being triggered:
> > > > >
> > > > > When starting:
> > > > >
> > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
> > > > >
> > > > > On connect:
> > > > >
> > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
> > > > >
> > > > > If those lines are not being triggered it is likely a client problem
> > > > > which for some reason had not subscribed to received service changes
> > > > > for some reason, if it doesn't subscribe to service changes then it
> > > > > shall not cache any attribute and attempt to rediscover on every
> > > > > connection.
> > > > >
> > > > > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > > > > >
> > > > > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > > > > >
> > > > > > Questions:
> > > > > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > > > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > > > > 3. Is there anything else we should look into?
> > > > > >
> > > > > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > > > > >
> > > > > > Thanks!
> > > > > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Luiz Augusto von Dentz
> >
> >
> >
> > --
> > Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-16 0:49 ` Luiz Augusto von Dentz
@ 2021-04-16 3:06 ` Kenny Bian
2021-04-16 4:03 ` Kenny Bian
0 siblings, 1 reply; 13+ messages in thread
From: Kenny Bian @ 2021-04-16 3:06 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Jamie Mccrae, linux-bluetooth
Hi Luiz,
Thank you so much! You're absolutely right.
I'll talk to our team to upgrade our Ubuntu to 20.04 LTS. Then I'll
test the BlueZ 5.53 which is the latest version on Ubuntu 20.04 LTS.
Thanks again!
Kenny
On Thu, Apr 15, 2021 at 5:49 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Kenny,
>
> On Thu, Apr 15, 2021 at 5:21 PM Kenny Bian <kennybian@gmail.com> wrote:
> >
> > Hi Luiz,
> >
> > Thank you so much. I appreciate it.
> >
> > That was my bad. I just checked. Our system is Ubuntu 18.04. The BlueZ
> > version is "5.48-0ubuntu3.4" which is different from the versions in
> > http://www.bluez.org/. I'm trying to figure out if this version
> > includes the version 5.50. Do you know the corresponding BlueZ version
> > for "5.48-0ubuntu3.4"?
>
> 5.48, which was the version available in 2018, more than 3 years/10
> releases ago, a lot of things have been fixed over this time so Id
> really recommend to upgrade to the latest if you want to have some
> support.
>
> > Thanks!
> > Kenny
> >
> > On Thu, Apr 15, 2021 at 1:31 PM Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> wrote:
> > >
> > > Hi Kenny,
> > >
> > > On Wed, Apr 14, 2021 at 10:44 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > >
> > > > Hi Luiz,
> > > >
> > > > There is a UI example of nRF Connect which shows the "Service Changed
> > > > Indication" is under "Generic
> > > > Attribute"(http://forum.espruino.com/conversations/357737/). We're
> > > > using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
> > >
> > >
> > > You should have mentioned that you are using 5.48, you need the following patch:
> > >
> > > commit a0b886e26c83ad4dfbf0b2b2e024c8ce9ead9a7d
> > > Author: Szymon Janc <szymon.janc@codecoup.pl>
> > > Date: Wed Mar 28 12:10:55 2018 +0200
> > >
> > > gatt: Add support for storing Service Changed CCC value
> > >
> > > This adds support for storing CCC value of Service Changed
> > > characteristic. Once bluetoothd is restart stored values are read
> > > and any device subscribed to indications will receive Service Changed
> > > indication with 0x00010-0xffff value. This is to invalidate any
> > > non-core services since there is no way to verify if applications
> > > will register their services in same order (or at all).
> > >
> > > This fix accessing invalid handles by stacks that rely only on Service
> > > Changed indication for rediscovery ie. Apple iOS.
> > >
> > > Or upgrade to a BlueZ release that has the above patch, which should be 5.50:
> > >
> > > +ver 5.50:
> > > + Fix issue with GATT and reading long values.
> > > + Fix issue with GATT and reading multiple includes.
> > > + Fix issue with GATT and service changes when offline.
> > > + Fix issue with handling secondary service discovery.
> > > + Fix issue with handling persistency of CCC values.
> > >
> > > >
> > > > class ServiceChangedChrc(Characteristic):
> > > > SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
> > > >
> > > > def __init__(self, bus, index, service):
> > > > Characteristic.__init__(
> > > > self, bus, index,
> > > > self.SCI_UUID,
> > > > ['indicate'],
> > > > service)
> > > >
> > > > def IndicateValue(self, options):
> > > > # This function doesn't exist. Just list it here.
> > > > pass
> > > >
> > > >
> > > > class ServiceChangedService(Service):
> > > > MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
> > > >
> > > > def __init__(self, bus, index):
> > > > Service.__init__(self, bus, index, self.MY_UUID, True)
> > > > self.add_characteristic(ServiceChangedChrc(bus, 0, self))
> > > >
> > > >
> > > > class Application(dbus.service.Object):
> > > > """
> > > > org.bluez.GattApplication1 interface implementation
> > > > """
> > > > def __init__(self, bus):
> > > > self.path = '/'
> > > > self.services = []
> > > > dbus.service.Object.__init__(self, bus, self.path)
> > > > self.add_service(HeartRateService(bus, 0))
> > > > self.add_service(BatteryService(bus, 1))
> > > > self.add_service(TestService(bus, 2))
> > > > self.add_service(ServiceChangedService(bus, 3))
> > > >
> > > >
> > > > When I run it, there is "Failed to register application:
> > > > org.bluez.Error.Failed: Failed to create entry in database". That is
> > > > in the function client_ready_cb() in gatt-database.c in BlueZ code. Do
> > > > you know how to fix it?
> > >
> > > You don't need to register Service Changed, the daemon already takes
> > > care of registering it and there could only be one Service Changed in
> > > the database.
> > >
> > > > Thanks!
> > > > Kenny
> > > >
> > > > On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > > >
> > > > > Hi Jamie, Luiz,
> > > > >
> > > > > Thanks for your info.
> > > > >
> > > > > Luiz, to answer your questions:
> > > > > BlueZ doesn't seem to emit "Service Changed Indication". Or it does
> > > > > emit it, but we don't know how to verify it.
> > > > > Yes, BlueZ acts as a GATT server which runs on Linux.
> > > > >
> > > > > So my questions:
> > > > > How can I tell if "Service Changed Indication" is working? I need to
> > > > > show it to our app developers that the GATT server does send the
> > > > > "Service Changed Indication" when there is a service change.
> > > > > By disabling the GATT's cache in "/etc/bluetooth/main.conf", the
> > > > > "Service Changed Indication" is disabled?
> > > > > Can "Service Changed Indication" be enabled in a conf file? Or should
> > > > > it be done in the Python code? Could you please help find out that
> > > > > info?
> > > > > Our GATT server is based on the Python code
> > > > > examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> > > > > I don't know how to enable "Service Changed Indication" or "Robust
> > > > > Caching" in Python code on the GATT server side. There is no document
> > > > > or code samples about that. Please let me know if there is any
> > > > > document or Python code example.
> > > > >
> > > > > Thanks!
> > > > > Kenny
> > > > >
> > > > > On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> > > > > <luiz.dentz@gmail.com> wrote:
> > > > > >
> > > > > > Hi Jamie, Brian,
> > > > > >
> > > > > > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > > > > > <Jamie.Mccrae@lairdconnect.com> wrote:
> > > > > > >
> > > > > > > Hi Kenny,
> > > > > > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> > > > > >
> > > > > > Yep, and while at it implement the so called Robust Caching feature so
> > > > > > we can detect if anything has changed by reading the DB Hash.
> > > > > >
> > > > > > > Thanks,
> > > > > > > Jamie
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kenny Bian <kennybian@gmail.com>
> > > > > > > Sent: 13 April 2021 06:59
> > > > > > > To: linux-bluetooth@vger.kernel.org
> > > > > > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > > > > > >
> > > > > > > EXTERNAL EMAIL: Be careful with attachments and links.
> > > > > > >
> > > > > > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > > > > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > > > > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > > > > > folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> > > > > > > "/etc/bluetooth/main.conf":
> > > > > > > [GATT]
> > > > > > > Cache = no
> > > > > >
> > > > > > When you say the app can't handle changed service do you mean BlueZ
> > > > > > doesn't emit changes to the attributes (via Service Changed) or is it
> > > > > > really the application not being able to handle the changes?
> > > > > >
> > > > > > > But recently, we saw the problem again even if the bluetooth cache is
> > > > > > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> > > > > >
> > > > > > So BlueZ is acting as the server, right? The Cache only applies to the
> > > > > > client portion, there is no such thing as disabling the remote cache.
> > > > > > I don't see any incoming Read By Group Request from the remote so it
> > > > > > is very likely that it has cached the values, there is no Read By Type
> > > > > > for the DB Hash either which is quite surprising to me since that is
> > > > > > required for stacks supporting Robust Caching which I believe is the
> > > > > > case of iOS.
> > > > > >
> > > > > > Anyway, I would check that the following lines are being triggered:
> > > > > >
> > > > > > When starting:
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
> > > > > >
> > > > > > On connect:
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
> > > > > >
> > > > > > If those lines are not being triggered it is likely a client problem
> > > > > > which for some reason had not subscribed to received service changes
> > > > > > for some reason, if it doesn't subscribe to service changes then it
> > > > > > shall not cache any attribute and attempt to rediscover on every
> > > > > > connection.
> > > > > >
> > > > > > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > > > > > >
> > > > > > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > > > > > >
> > > > > > > Questions:
> > > > > > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > > > > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > > > > > 3. Is there anything else we should look into?
> > > > > > >
> > > > > > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Luiz Augusto von Dentz
> > >
> > >
> > >
> > > --
> > > Luiz Augusto von Dentz
>
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-16 3:06 ` Kenny Bian
@ 2021-04-16 4:03 ` Kenny Bian
2021-04-16 6:34 ` Jamie Mccrae
0 siblings, 1 reply; 13+ messages in thread
From: Kenny Bian @ 2021-04-16 4:03 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Jamie Mccrae, linux-bluetooth
Hi Luiz,
One more question. Once we upgrade our device to Ubuntu 20.04 LTS with
BlueZ 5.53, we'll test "Service Changed Indication". Is GATT cache
related to "Service Changed Indication"? If they are related, then I
guess we should turn on the GATT cache in /etc/bluetooth/main.conf?
Right now, the GATT cache is turned off in our device.
Thanks,
Kenny
On Thu, Apr 15, 2021 at 8:06 PM Kenny Bian <kennybian@gmail.com> wrote:
>
> Hi Luiz,
>
> Thank you so much! You're absolutely right.
>
> I'll talk to our team to upgrade our Ubuntu to 20.04 LTS. Then I'll
> test the BlueZ 5.53 which is the latest version on Ubuntu 20.04 LTS.
>
> Thanks again!
> Kenny
>
> On Thu, Apr 15, 2021 at 5:49 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Kenny,
> >
> > On Thu, Apr 15, 2021 at 5:21 PM Kenny Bian <kennybian@gmail.com> wrote:
> > >
> > > Hi Luiz,
> > >
> > > Thank you so much. I appreciate it.
> > >
> > > That was my bad. I just checked. Our system is Ubuntu 18.04. The BlueZ
> > > version is "5.48-0ubuntu3.4" which is different from the versions in
> > > http://www.bluez.org/. I'm trying to figure out if this version
> > > includes the version 5.50. Do you know the corresponding BlueZ version
> > > for "5.48-0ubuntu3.4"?
> >
> > 5.48, which was the version available in 2018, more than 3 years/10
> > releases ago, a lot of things have been fixed over this time so Id
> > really recommend to upgrade to the latest if you want to have some
> > support.
> >
> > > Thanks!
> > > Kenny
> > >
> > > On Thu, Apr 15, 2021 at 1:31 PM Luiz Augusto von Dentz
> > > <luiz.dentz@gmail.com> wrote:
> > > >
> > > > Hi Kenny,
> > > >
> > > > On Wed, Apr 14, 2021 at 10:44 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > > >
> > > > > Hi Luiz,
> > > > >
> > > > > There is a UI example of nRF Connect which shows the "Service Changed
> > > > > Indication" is under "Generic
> > > > > Attribute"(http://forum.espruino.com/conversations/357737/). We're
> > > > > using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
> > > >
> > > >
> > > > You should have mentioned that you are using 5.48, you need the following patch:
> > > >
> > > > commit a0b886e26c83ad4dfbf0b2b2e024c8ce9ead9a7d
> > > > Author: Szymon Janc <szymon.janc@codecoup.pl>
> > > > Date: Wed Mar 28 12:10:55 2018 +0200
> > > >
> > > > gatt: Add support for storing Service Changed CCC value
> > > >
> > > > This adds support for storing CCC value of Service Changed
> > > > characteristic. Once bluetoothd is restart stored values are read
> > > > and any device subscribed to indications will receive Service Changed
> > > > indication with 0x00010-0xffff value. This is to invalidate any
> > > > non-core services since there is no way to verify if applications
> > > > will register their services in same order (or at all).
> > > >
> > > > This fix accessing invalid handles by stacks that rely only on Service
> > > > Changed indication for rediscovery ie. Apple iOS.
> > > >
> > > > Or upgrade to a BlueZ release that has the above patch, which should be 5.50:
> > > >
> > > > +ver 5.50:
> > > > + Fix issue with GATT and reading long values.
> > > > + Fix issue with GATT and reading multiple includes.
> > > > + Fix issue with GATT and service changes when offline.
> > > > + Fix issue with handling secondary service discovery.
> > > > + Fix issue with handling persistency of CCC values.
> > > >
> > > > >
> > > > > class ServiceChangedChrc(Characteristic):
> > > > > SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
> > > > >
> > > > > def __init__(self, bus, index, service):
> > > > > Characteristic.__init__(
> > > > > self, bus, index,
> > > > > self.SCI_UUID,
> > > > > ['indicate'],
> > > > > service)
> > > > >
> > > > > def IndicateValue(self, options):
> > > > > # This function doesn't exist. Just list it here.
> > > > > pass
> > > > >
> > > > >
> > > > > class ServiceChangedService(Service):
> > > > > MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
> > > > >
> > > > > def __init__(self, bus, index):
> > > > > Service.__init__(self, bus, index, self.MY_UUID, True)
> > > > > self.add_characteristic(ServiceChangedChrc(bus, 0, self))
> > > > >
> > > > >
> > > > > class Application(dbus.service.Object):
> > > > > """
> > > > > org.bluez.GattApplication1 interface implementation
> > > > > """
> > > > > def __init__(self, bus):
> > > > > self.path = '/'
> > > > > self.services = []
> > > > > dbus.service.Object.__init__(self, bus, self.path)
> > > > > self.add_service(HeartRateService(bus, 0))
> > > > > self.add_service(BatteryService(bus, 1))
> > > > > self.add_service(TestService(bus, 2))
> > > > > self.add_service(ServiceChangedService(bus, 3))
> > > > >
> > > > >
> > > > > When I run it, there is "Failed to register application:
> > > > > org.bluez.Error.Failed: Failed to create entry in database". That is
> > > > > in the function client_ready_cb() in gatt-database.c in BlueZ code. Do
> > > > > you know how to fix it?
> > > >
> > > > You don't need to register Service Changed, the daemon already takes
> > > > care of registering it and there could only be one Service Changed in
> > > > the database.
> > > >
> > > > > Thanks!
> > > > > Kenny
> > > > >
> > > > > On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > > > >
> > > > > > Hi Jamie, Luiz,
> > > > > >
> > > > > > Thanks for your info.
> > > > > >
> > > > > > Luiz, to answer your questions:
> > > > > > BlueZ doesn't seem to emit "Service Changed Indication". Or it does
> > > > > > emit it, but we don't know how to verify it.
> > > > > > Yes, BlueZ acts as a GATT server which runs on Linux.
> > > > > >
> > > > > > So my questions:
> > > > > > How can I tell if "Service Changed Indication" is working? I need to
> > > > > > show it to our app developers that the GATT server does send the
> > > > > > "Service Changed Indication" when there is a service change.
> > > > > > By disabling the GATT's cache in "/etc/bluetooth/main.conf", the
> > > > > > "Service Changed Indication" is disabled?
> > > > > > Can "Service Changed Indication" be enabled in a conf file? Or should
> > > > > > it be done in the Python code? Could you please help find out that
> > > > > > info?
> > > > > > Our GATT server is based on the Python code
> > > > > > examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> > > > > > I don't know how to enable "Service Changed Indication" or "Robust
> > > > > > Caching" in Python code on the GATT server side. There is no document
> > > > > > or code samples about that. Please let me know if there is any
> > > > > > document or Python code example.
> > > > > >
> > > > > > Thanks!
> > > > > > Kenny
> > > > > >
> > > > > > On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> > > > > > <luiz.dentz@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Jamie, Brian,
> > > > > > >
> > > > > > > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > > > > > > <Jamie.Mccrae@lairdconnect.com> wrote:
> > > > > > > >
> > > > > > > > Hi Kenny,
> > > > > > > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> > > > > > >
> > > > > > > Yep, and while at it implement the so called Robust Caching feature so
> > > > > > > we can detect if anything has changed by reading the DB Hash.
> > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jamie
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Kenny Bian <kennybian@gmail.com>
> > > > > > > > Sent: 13 April 2021 06:59
> > > > > > > > To: linux-bluetooth@vger.kernel.org
> > > > > > > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > > > > > > >
> > > > > > > > EXTERNAL EMAIL: Be careful with attachments and links.
> > > > > > > >
> > > > > > > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > > > > > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > > > > > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > > > > > > folder is copied over to the new build's partition. We realized that there is no "service changed indication". The app can't handle the changed services. So we disabled the bluetooth cache by set this in
> > > > > > > > "/etc/bluetooth/main.conf":
> > > > > > > > [GATT]
> > > > > > > > Cache = no
> > > > > > >
> > > > > > > When you say the app can't handle changed service do you mean BlueZ
> > > > > > > doesn't emit changes to the attributes (via Service Changed) or is it
> > > > > > > really the application not being able to handle the changes?
> > > > > > >
> > > > > > > > But recently, we saw the problem again even if the bluetooth cache is
> > > > > > > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> > > > > > >
> > > > > > > So BlueZ is acting as the server, right? The Cache only applies to the
> > > > > > > client portion, there is no such thing as disabling the remote cache.
> > > > > > > I don't see any incoming Read By Group Request from the remote so it
> > > > > > > is very likely that it has cached the values, there is no Read By Type
> > > > > > > for the DB Hash either which is quite surprising to me since that is
> > > > > > > required for stacks supporting Robust Caching which I believe is the
> > > > > > > case of iOS.
> > > > > > >
> > > > > > > Anyway, I would check that the following lines are being triggered:
> > > > > > >
> > > > > > > When starting:
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3798
> > > > > > >
> > > > > > > On connect:
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n3741
> > > > > > >
> > > > > > > If those lines are not being triggered it is likely a client problem
> > > > > > > which for some reason had not subscribed to received service changes
> > > > > > > for some reason, if it doesn't subscribe to service changes then it
> > > > > > > shall not cache any attribute and attempt to rediscover on every
> > > > > > > connection.
> > > > > > >
> > > > > > > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > > > > > > >
> > > > > > > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > > > > > > >
> > > > > > > > Questions:
> > > > > > > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > > > > > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > > > > > > 3. Is there anything else we should look into?
> > > > > > > >
> > > > > > > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Luiz Augusto von Dentz
> > > >
> > > >
> > > >
> > > > --
> > > > Luiz Augusto von Dentz
> >
> >
> >
> > --
> > Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-16 4:03 ` Kenny Bian
@ 2021-04-16 6:34 ` Jamie Mccrae
2021-04-20 21:35 ` Kenny Bian
0 siblings, 1 reply; 13+ messages in thread
From: Jamie Mccrae @ 2021-04-16 6:34 UTC (permalink / raw)
To: Kenny Bian, Luiz Augusto von Dentz; +Cc: linux-bluetooth
Hi Kenny,
The way it works is when a device connects (it might just be a normal connection, it might be only if it pairs, it's vender specific) it will generally cache the GATT table of the remote device, this is so that future connections are faster as it won't need to send multiple read commands to get it. The easy way for that device to know if the GATT table has changed is it uses a specific GATT attribute with a GATT table hash and reads that, if it's changed then it needs to clear the cache and re-read the table. That only works when a device connects and reads it, if the GATT table is updated during a connection, then an indication can be sent to that device telling it the GATT table hash has changed and it can re-read it and clear it during a connection.
If you are connecting a phone to your embedded device with the GATT table being on the embedded device then the cache is stored on the phone, there doesn't need to be a GATT table hash on the embedded device because the phone doesn't have a GATT table and iOS/android will create the cache themselves, you cannot disable that from the embedded device side, whatever cache you enable/disable on the embedded system is for that system only, it does not propagate that configuration value to other devices.
Thanks,
Jamie
-----Original Message-----
From: Kenny Bian <kennybian@gmail.com>
Sent: 16 April 2021 05:03
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Jamie Mccrae <Jamie.Mccrae@lairdconnect.com>; linux-bluetooth@vger.kernel.org
Subject: Re: Disabled bluetooth cache. But the app still getting wrong data?
EXTERNAL EMAIL: Be careful with attachments and links.
Hi Luiz,
One more question. Once we upgrade our device to Ubuntu 20.04 LTS with BlueZ 5.53, we'll test "Service Changed Indication". Is GATT cache related to "Service Changed Indication"? If they are related, then I guess we should turn on the GATT cache in /etc/bluetooth/main.conf?
Right now, the GATT cache is turned off in our device.
Thanks,
Kenny
On Thu, Apr 15, 2021 at 8:06 PM Kenny Bian <kennybian@gmail.com> wrote:
>
> Hi Luiz,
>
> Thank you so much! You're absolutely right.
>
> I'll talk to our team to upgrade our Ubuntu to 20.04 LTS. Then I'll
> test the BlueZ 5.53 which is the latest version on Ubuntu 20.04 LTS.
>
> Thanks again!
> Kenny
>
> On Thu, Apr 15, 2021 at 5:49 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Kenny,
> >
> > On Thu, Apr 15, 2021 at 5:21 PM Kenny Bian <kennybian@gmail.com> wrote:
> > >
> > > Hi Luiz,
> > >
> > > Thank you so much. I appreciate it.
> > >
> > > That was my bad. I just checked. Our system is Ubuntu 18.04. The
> > > BlueZ version is "5.48-0ubuntu3.4" which is different from the
> > > versions in http://www.bluez.org/. I'm trying to figure out if
> > > this version includes the version 5.50. Do you know the
> > > corresponding BlueZ version for "5.48-0ubuntu3.4"?
> >
> > 5.48, which was the version available in 2018, more than 3 years/10
> > releases ago, a lot of things have been fixed over this time so Id
> > really recommend to upgrade to the latest if you want to have some
> > support.
> >
> > > Thanks!
> > > Kenny
> > >
> > > On Thu, Apr 15, 2021 at 1:31 PM Luiz Augusto von Dentz
> > > <luiz.dentz@gmail.com> wrote:
> > > >
> > > > Hi Kenny,
> > > >
> > > > On Wed, Apr 14, 2021 at 10:44 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > > >
> > > > > Hi Luiz,
> > > > >
> > > > > There is a UI example of nRF Connect which shows the "Service
> > > > > Changed Indication" is under "Generic
> > > > > Attribute"(http://forum.espruino.com/conversations/357737/).
> > > > > We're using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
> > > >
> > > >
> > > > You should have mentioned that you are using 5.48, you need the following patch:
> > > >
> > > > commit a0b886e26c83ad4dfbf0b2b2e024c8ce9ead9a7d
> > > > Author: Szymon Janc <szymon.janc@codecoup.pl>
> > > > Date: Wed Mar 28 12:10:55 2018 +0200
> > > >
> > > > gatt: Add support for storing Service Changed CCC value
> > > >
> > > > This adds support for storing CCC value of Service Changed
> > > > characteristic. Once bluetoothd is restart stored values are read
> > > > and any device subscribed to indications will receive Service Changed
> > > > indication with 0x00010-0xffff value. This is to invalidate any
> > > > non-core services since there is no way to verify if applications
> > > > will register their services in same order (or at all).
> > > >
> > > > This fix accessing invalid handles by stacks that rely only on Service
> > > > Changed indication for rediscovery ie. Apple iOS.
> > > >
> > > > Or upgrade to a BlueZ release that has the above patch, which should be 5.50:
> > > >
> > > > +ver 5.50:
> > > > + Fix issue with GATT and reading long values.
> > > > + Fix issue with GATT and reading multiple includes.
> > > > + Fix issue with GATT and service changes when offline.
> > > > + Fix issue with handling secondary service discovery.
> > > > + Fix issue with handling persistency of CCC values.
> > > >
> > > > >
> > > > > class ServiceChangedChrc(Characteristic):
> > > > > SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
> > > > >
> > > > > def __init__(self, bus, index, service):
> > > > > Characteristic.__init__(
> > > > > self, bus, index,
> > > > > self.SCI_UUID,
> > > > > ['indicate'],
> > > > > service)
> > > > >
> > > > > def IndicateValue(self, options):
> > > > > # This function doesn't exist. Just list it here.
> > > > > pass
> > > > >
> > > > >
> > > > > class ServiceChangedService(Service):
> > > > > MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
> > > > >
> > > > > def __init__(self, bus, index):
> > > > > Service.__init__(self, bus, index, self.MY_UUID, True)
> > > > > self.add_characteristic(ServiceChangedChrc(bus, 0,
> > > > > self))
> > > > >
> > > > >
> > > > > class Application(dbus.service.Object):
> > > > > """
> > > > > org.bluez.GattApplication1 interface implementation
> > > > > """
> > > > > def __init__(self, bus):
> > > > > self.path = '/'
> > > > > self.services = []
> > > > > dbus.service.Object.__init__(self, bus, self.path)
> > > > > self.add_service(HeartRateService(bus, 0))
> > > > > self.add_service(BatteryService(bus, 1))
> > > > > self.add_service(TestService(bus, 2))
> > > > > self.add_service(ServiceChangedService(bus, 3))
> > > > >
> > > > >
> > > > > When I run it, there is "Failed to register application:
> > > > > org.bluez.Error.Failed: Failed to create entry in database".
> > > > > That is in the function client_ready_cb() in gatt-database.c
> > > > > in BlueZ code. Do you know how to fix it?
> > > >
> > > > You don't need to register Service Changed, the daemon already
> > > > takes care of registering it and there could only be one Service
> > > > Changed in the database.
> > > >
> > > > > Thanks!
> > > > > Kenny
> > > > >
> > > > > On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > > > >
> > > > > > Hi Jamie, Luiz,
> > > > > >
> > > > > > Thanks for your info.
> > > > > >
> > > > > > Luiz, to answer your questions:
> > > > > > BlueZ doesn't seem to emit "Service Changed Indication". Or
> > > > > > it does emit it, but we don't know how to verify it.
> > > > > > Yes, BlueZ acts as a GATT server which runs on Linux.
> > > > > >
> > > > > > So my questions:
> > > > > > How can I tell if "Service Changed Indication" is working? I
> > > > > > need to show it to our app developers that the GATT server
> > > > > > does send the "Service Changed Indication" when there is a service change.
> > > > > > By disabling the GATT's cache in "/etc/bluetooth/main.conf",
> > > > > > the "Service Changed Indication" is disabled?
> > > > > > Can "Service Changed Indication" be enabled in a conf file?
> > > > > > Or should it be done in the Python code? Could you please
> > > > > > help find out that info?
> > > > > > Our GATT server is based on the Python code
> > > > > > examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> > > > > > I don't know how to enable "Service Changed Indication" or
> > > > > > "Robust Caching" in Python code on the GATT server side.
> > > > > > There is no document or code samples about that. Please let
> > > > > > me know if there is any document or Python code example.
> > > > > >
> > > > > > Thanks!
> > > > > > Kenny
> > > > > >
> > > > > > On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> > > > > > <luiz.dentz@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Jamie, Brian,
> > > > > > >
> > > > > > > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > > > > > > <Jamie.Mccrae@lairdconnect.com> wrote:
> > > > > > > >
> > > > > > > > Hi Kenny,
> > > > > > > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> > > > > > >
> > > > > > > Yep, and while at it implement the so called Robust
> > > > > > > Caching feature so we can detect if anything has changed by reading the DB Hash.
> > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jamie
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Kenny Bian <kennybian@gmail.com>
> > > > > > > > Sent: 13 April 2021 06:59
> > > > > > > > To: linux-bluetooth@vger.kernel.org
> > > > > > > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > > > > > > >
> > > > > > > > EXTERNAL EMAIL: Be careful with attachments and links.
> > > > > > > >
> > > > > > > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > > > > > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > > > > > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > > > > > > folder is copied over to the new build's partition. We
> > > > > > > > realized that there is no "service changed indication".
> > > > > > > > The app can't handle the changed services. So we
> > > > > > > > disabled the bluetooth cache by set this in
> > > > > > > > "/etc/bluetooth/main.conf":
> > > > > > > > [GATT]
> > > > > > > > Cache = no
> > > > > > >
> > > > > > > When you say the app can't handle changed service do you
> > > > > > > mean BlueZ doesn't emit changes to the attributes (via
> > > > > > > Service Changed) or is it really the application not being able to handle the changes?
> > > > > > >
> > > > > > > > But recently, we saw the problem again even if the
> > > > > > > > bluetooth cache is
> > > > > > > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> > > > > > >
> > > > > > > So BlueZ is acting as the server, right? The Cache only
> > > > > > > applies to the client portion, there is no such thing as disabling the remote cache.
> > > > > > > I don't see any incoming Read By Group Request from the
> > > > > > > remote so it is very likely that it has cached the values,
> > > > > > > there is no Read By Type for the DB Hash either which is
> > > > > > > quite surprising to me since that is required for stacks
> > > > > > > supporting Robust Caching which I believe is the case of iOS.
> > > > > > >
> > > > > > > Anyway, I would check that the following lines are being triggered:
> > > > > > >
> > > > > > > When starting:
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/sr
> > > > > > > c/gatt-database.c#n3798
> > > > > > >
> > > > > > > On connect:
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/sr
> > > > > > > c/gatt-database.c#n3741
> > > > > > >
> > > > > > > If those lines are not being triggered it is likely a
> > > > > > > client problem which for some reason had not subscribed to
> > > > > > > received service changes for some reason, if it doesn't
> > > > > > > subscribe to service changes then it shall not cache any
> > > > > > > attribute and attempt to rediscover on every connection.
> > > > > > >
> > > > > > > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > > > > > > >
> > > > > > > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > > > > > > >
> > > > > > > > Questions:
> > > > > > > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > > > > > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > > > > > > 3. Is there anything else we should look into?
> > > > > > > >
> > > > > > > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Luiz Augusto von Dentz
> > > >
> > > >
> > > >
> > > > --
> > > > Luiz Augusto von Dentz
> >
> >
> >
> > --
> > Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Disabled bluetooth cache. But the app still getting wrong data?
2021-04-16 6:34 ` Jamie Mccrae
@ 2021-04-20 21:35 ` Kenny Bian
0 siblings, 0 replies; 13+ messages in thread
From: Kenny Bian @ 2021-04-20 21:35 UTC (permalink / raw)
To: Jamie Mccrae; +Cc: Luiz Augusto von Dentz, linux-bluetooth
Thank you so much, Jamie. That well explained it.
On Thu, Apr 15, 2021 at 11:34 PM Jamie Mccrae
<Jamie.Mccrae@lairdconnect.com> wrote:
>
> Hi Kenny,
> The way it works is when a device connects (it might just be a normal connection, it might be only if it pairs, it's vender specific) it will generally cache the GATT table of the remote device, this is so that future connections are faster as it won't need to send multiple read commands to get it. The easy way for that device to know if the GATT table has changed is it uses a specific GATT attribute with a GATT table hash and reads that, if it's changed then it needs to clear the cache and re-read the table. That only works when a device connects and reads it, if the GATT table is updated during a connection, then an indication can be sent to that device telling it the GATT table hash has changed and it can re-read it and clear it during a connection.
> If you are connecting a phone to your embedded device with the GATT table being on the embedded device then the cache is stored on the phone, there doesn't need to be a GATT table hash on the embedded device because the phone doesn't have a GATT table and iOS/android will create the cache themselves, you cannot disable that from the embedded device side, whatever cache you enable/disable on the embedded system is for that system only, it does not propagate that configuration value to other devices.
> Thanks,
> Jamie
>
> -----Original Message-----
> From: Kenny Bian <kennybian@gmail.com>
> Sent: 16 April 2021 05:03
> To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> Cc: Jamie Mccrae <Jamie.Mccrae@lairdconnect.com>; linux-bluetooth@vger.kernel.org
> Subject: Re: Disabled bluetooth cache. But the app still getting wrong data?
>
> EXTERNAL EMAIL: Be careful with attachments and links.
>
> Hi Luiz,
>
> One more question. Once we upgrade our device to Ubuntu 20.04 LTS with BlueZ 5.53, we'll test "Service Changed Indication". Is GATT cache related to "Service Changed Indication"? If they are related, then I guess we should turn on the GATT cache in /etc/bluetooth/main.conf?
> Right now, the GATT cache is turned off in our device.
>
> Thanks,
> Kenny
>
> On Thu, Apr 15, 2021 at 8:06 PM Kenny Bian <kennybian@gmail.com> wrote:
> >
> > Hi Luiz,
> >
> > Thank you so much! You're absolutely right.
> >
> > I'll talk to our team to upgrade our Ubuntu to 20.04 LTS. Then I'll
> > test the BlueZ 5.53 which is the latest version on Ubuntu 20.04 LTS.
> >
> > Thanks again!
> > Kenny
> >
> > On Thu, Apr 15, 2021 at 5:49 PM Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> wrote:
> > >
> > > Hi Kenny,
> > >
> > > On Thu, Apr 15, 2021 at 5:21 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > >
> > > > Hi Luiz,
> > > >
> > > > Thank you so much. I appreciate it.
> > > >
> > > > That was my bad. I just checked. Our system is Ubuntu 18.04. The
> > > > BlueZ version is "5.48-0ubuntu3.4" which is different from the
> > > > versions in http://www.bluez.org/. I'm trying to figure out if
> > > > this version includes the version 5.50. Do you know the
> > > > corresponding BlueZ version for "5.48-0ubuntu3.4"?
> > >
> > > 5.48, which was the version available in 2018, more than 3 years/10
> > > releases ago, a lot of things have been fixed over this time so Id
> > > really recommend to upgrade to the latest if you want to have some
> > > support.
> > >
> > > > Thanks!
> > > > Kenny
> > > >
> > > > On Thu, Apr 15, 2021 at 1:31 PM Luiz Augusto von Dentz
> > > > <luiz.dentz@gmail.com> wrote:
> > > > >
> > > > > Hi Kenny,
> > > > >
> > > > > On Wed, Apr 14, 2021 at 10:44 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > > > >
> > > > > > Hi Luiz,
> > > > > >
> > > > > > There is a UI example of nRF Connect which shows the "Service
> > > > > > Changed Indication" is under "Generic
> > > > > > Attribute"(http://forum.espruino.com/conversations/357737/).
> > > > > > We're using BlueZ 5.48. I tried to add it by modifying example-gatt-server:
> > > > >
> > > > >
> > > > > You should have mentioned that you are using 5.48, you need the following patch:
> > > > >
> > > > > commit a0b886e26c83ad4dfbf0b2b2e024c8ce9ead9a7d
> > > > > Author: Szymon Janc <szymon.janc@codecoup.pl>
> > > > > Date: Wed Mar 28 12:10:55 2018 +0200
> > > > >
> > > > > gatt: Add support for storing Service Changed CCC value
> > > > >
> > > > > This adds support for storing CCC value of Service Changed
> > > > > characteristic. Once bluetoothd is restart stored values are read
> > > > > and any device subscribed to indications will receive Service Changed
> > > > > indication with 0x00010-0xffff value. This is to invalidate any
> > > > > non-core services since there is no way to verify if applications
> > > > > will register their services in same order (or at all).
> > > > >
> > > > > This fix accessing invalid handles by stacks that rely only on Service
> > > > > Changed indication for rediscovery ie. Apple iOS.
> > > > >
> > > > > Or upgrade to a BlueZ release that has the above patch, which should be 5.50:
> > > > >
> > > > > +ver 5.50:
> > > > > + Fix issue with GATT and reading long values.
> > > > > + Fix issue with GATT and reading multiple includes.
> > > > > + Fix issue with GATT and service changes when offline.
> > > > > + Fix issue with handling secondary service discovery.
> > > > > + Fix issue with handling persistency of CCC values.
> > > > >
> > > > > >
> > > > > > class ServiceChangedChrc(Characteristic):
> > > > > > SCI_UUID = '00002a05-0000-1000-8000-00805f9b34fb'
> > > > > >
> > > > > > def __init__(self, bus, index, service):
> > > > > > Characteristic.__init__(
> > > > > > self, bus, index,
> > > > > > self.SCI_UUID,
> > > > > > ['indicate'],
> > > > > > service)
> > > > > >
> > > > > > def IndicateValue(self, options):
> > > > > > # This function doesn't exist. Just list it here.
> > > > > > pass
> > > > > >
> > > > > >
> > > > > > class ServiceChangedService(Service):
> > > > > > MY_UUID = '00001801-0000-1000-8000-00805f9b34fb'
> > > > > >
> > > > > > def __init__(self, bus, index):
> > > > > > Service.__init__(self, bus, index, self.MY_UUID, True)
> > > > > > self.add_characteristic(ServiceChangedChrc(bus, 0,
> > > > > > self))
> > > > > >
> > > > > >
> > > > > > class Application(dbus.service.Object):
> > > > > > """
> > > > > > org.bluez.GattApplication1 interface implementation
> > > > > > """
> > > > > > def __init__(self, bus):
> > > > > > self.path = '/'
> > > > > > self.services = []
> > > > > > dbus.service.Object.__init__(self, bus, self.path)
> > > > > > self.add_service(HeartRateService(bus, 0))
> > > > > > self.add_service(BatteryService(bus, 1))
> > > > > > self.add_service(TestService(bus, 2))
> > > > > > self.add_service(ServiceChangedService(bus, 3))
> > > > > >
> > > > > >
> > > > > > When I run it, there is "Failed to register application:
> > > > > > org.bluez.Error.Failed: Failed to create entry in database".
> > > > > > That is in the function client_ready_cb() in gatt-database.c
> > > > > > in BlueZ code. Do you know how to fix it?
> > > > >
> > > > > You don't need to register Service Changed, the daemon already
> > > > > takes care of registering it and there could only be one Service
> > > > > Changed in the database.
> > > > >
> > > > > > Thanks!
> > > > > > Kenny
> > > > > >
> > > > > > On Tue, Apr 13, 2021 at 9:46 PM Kenny Bian <kennybian@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Jamie, Luiz,
> > > > > > >
> > > > > > > Thanks for your info.
> > > > > > >
> > > > > > > Luiz, to answer your questions:
> > > > > > > BlueZ doesn't seem to emit "Service Changed Indication". Or
> > > > > > > it does emit it, but we don't know how to verify it.
> > > > > > > Yes, BlueZ acts as a GATT server which runs on Linux.
> > > > > > >
> > > > > > > So my questions:
> > > > > > > How can I tell if "Service Changed Indication" is working? I
> > > > > > > need to show it to our app developers that the GATT server
> > > > > > > does send the "Service Changed Indication" when there is a service change.
> > > > > > > By disabling the GATT's cache in "/etc/bluetooth/main.conf",
> > > > > > > the "Service Changed Indication" is disabled?
> > > > > > > Can "Service Changed Indication" be enabled in a conf file?
> > > > > > > Or should it be done in the Python code? Could you please
> > > > > > > help find out that info?
> > > > > > > Our GATT server is based on the Python code
> > > > > > > examples(https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
> > > > > > > I don't know how to enable "Service Changed Indication" or
> > > > > > > "Robust Caching" in Python code on the GATT server side.
> > > > > > > There is no document or code samples about that. Please let
> > > > > > > me know if there is any document or Python code example.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Kenny
> > > > > > >
> > > > > > > On Tue, Apr 13, 2021 at 2:57 PM Luiz Augusto von Dentz
> > > > > > > <luiz.dentz@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Jamie, Brian,
> > > > > > > >
> > > > > > > > On Tue, Apr 13, 2021 at 2:03 AM Jamie Mccrae
> > > > > > > > <Jamie.Mccrae@lairdconnect.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Kenny,
> > > > > > > > > Why not just add the service changed indication as you refer to below? It was purposely designed for this specific purpose, you're trying to work around an issue created because you don't want to use the feature that prevents this issue. Any workaround is just that, a workaround, and might not work as intended.
> > > > > > > >
> > > > > > > > Yep, and while at it implement the so called Robust
> > > > > > > > Caching feature so we can detect if anything has changed by reading the DB Hash.
> > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Jamie
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Kenny Bian <kennybian@gmail.com>
> > > > > > > > > Sent: 13 April 2021 06:59
> > > > > > > > > To: linux-bluetooth@vger.kernel.org
> > > > > > > > > Subject: Disabled bluetooth cache. But the app still getting wrong data?
> > > > > > > > >
> > > > > > > > > EXTERNAL EMAIL: Be careful with attachments and links.
> > > > > > > > >
> > > > > > > > > Previously we had an issue: if there is a change of characteristics in the new build of our firmware, then the app will get the wrong data.
> > > > > > > > > By saying changed characteristics, it can be an added or removed characteristic, or adding notification to an existing characteristic.
> > > > > > > > > In order to keep the pairing information, the "/var/lib/bluetooth"
> > > > > > > > > folder is copied over to the new build's partition. We
> > > > > > > > > realized that there is no "service changed indication".
> > > > > > > > > The app can't handle the changed services. So we
> > > > > > > > > disabled the bluetooth cache by set this in
> > > > > > > > > "/etc/bluetooth/main.conf":
> > > > > > > > > [GATT]
> > > > > > > > > Cache = no
> > > > > > > >
> > > > > > > > When you say the app can't handle changed service do you
> > > > > > > > mean BlueZ doesn't emit changes to the attributes (via
> > > > > > > > Service Changed) or is it really the application not being able to handle the changes?
> > > > > > > >
> > > > > > > > > But recently, we saw the problem again even if the
> > > > > > > > > bluetooth cache is
> > > > > > > > > disabled: in the build number 101, a characteristic is removed. But when we upgrade the build from 100 to 101, the app gets the wrong data. We looked at the log. When the app tries to read temperature by using the temperature UUID, somehow the bluetooth service we created received the request to read the "device name"(device name UUID). So the "device name" is returned to the app as the temperature. This looks like the same behavior as the bluetooth cache is not disabled. I looked at the "/var/lib/bluetooth/[BT_MAC]/cache" folder. There is no "[Attributes]" section in the files in the folder. That means the disabled cache seems working.
> > > > > > > >
> > > > > > > > So BlueZ is acting as the server, right? The Cache only
> > > > > > > > applies to the client portion, there is no such thing as disabling the remote cache.
> > > > > > > > I don't see any incoming Read By Group Request from the
> > > > > > > > remote so it is very likely that it has cached the values,
> > > > > > > > there is no Read By Type for the DB Hash either which is
> > > > > > > > quite surprising to me since that is required for stacks
> > > > > > > > supporting Robust Caching which I believe is the case of iOS.
> > > > > > > >
> > > > > > > > Anyway, I would check that the following lines are being triggered:
> > > > > > > >
> > > > > > > > When starting:
> > > > > > > >
> > > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/sr
> > > > > > > > c/gatt-database.c#n3798
> > > > > > > >
> > > > > > > > On connect:
> > > > > > > >
> > > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/sr
> > > > > > > > c/gatt-database.c#n3741
> > > > > > > >
> > > > > > > > If those lines are not being triggered it is likely a
> > > > > > > > client problem which for some reason had not subscribed to
> > > > > > > > received service changes for some reason, if it doesn't
> > > > > > > > subscribe to service changes then it shall not cache any
> > > > > > > > attribute and attempt to rediscover on every connection.
> > > > > > > >
> > > > > > > > > The only way to fix this issue is to force exit the mobile app on the phone and "Forget This Device" in iOS or "Unpair" in Android.
> > > > > > > > >
> > > > > > > > > I looked at the btmon(see attached). For the working btmon log, there is "Attribute group list: XX entries" under "ACL Data TX". But there is no "Attribute group list: XX entries" under "ACL Data TX" in the attached problematic btmon log.
> > > > > > > > >
> > > > > > > > > Questions:
> > > > > > > > > 1. How is it possible that this still happens even if the bluetooth cache is disabled?
> > > > > > > > > 2. Is this the problem on the Linux side which runs the GATT server or on the mobile side?
> > > > > > > > > 3. Is there anything else we should look into?
> > > > > > > > >
> > > > > > > > > We're going to release our product soon. This is a critical issue for us. Please help if you have any suggestions.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Luiz Augusto von Dentz
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Luiz Augusto von Dentz
> > >
> > >
> > >
> > > --
> > > Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-04-20 21:35 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-13 5:59 Disabled bluetooth cache. But the app still getting wrong data? Kenny Bian
2021-04-13 6:39 ` Jamie Mccrae
2021-04-13 17:17 ` Kenny Bian
2021-04-13 21:57 ` Luiz Augusto von Dentz
2021-04-14 4:46 ` Kenny Bian
2021-04-15 5:44 ` Kenny Bian
2021-04-15 20:31 ` Luiz Augusto von Dentz
2021-04-16 0:20 ` Kenny Bian
2021-04-16 0:49 ` Luiz Augusto von Dentz
2021-04-16 3:06 ` Kenny Bian
2021-04-16 4:03 ` Kenny Bian
2021-04-16 6:34 ` Jamie Mccrae
2021-04-20 21:35 ` Kenny Bian
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.