Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAC9s0NZrReFB-6_JwHFqJtLwqSuYGzKbZMvDeKYzh+Jof9iUjg@mail.gmail.com>
In-Reply-To: <CAC9s0NZrReFB-6_JwHFqJtLwqSuYGzKbZMvDeKYzh+Jof9iUjg@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Wed, 17 Mar 2021 11:15:09 -0700
Message-ID: <CABBYNZJJ5Jymk=51E-aeWE4VyXGvXsgSjftYRJY47_tNzzJWHA@mail.gmail.com>
Subject: Re: Have to delete "/var/lib/bluetooth" folder in order to get all
 service characteristics available
To:     Kenny Bian <kennybian@gmail.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Kenny,

On Wed, Mar 17, 2021 at 12:40 AM Kenny Bian <kennybian@gmail.com> wrote:
>
> In order to keep the pairing information, we carry over the
> "/var/lib/bluetooth" folder from an older build to the new build in
> the Linux system when doing firmware upgrade. This way, our end user
> doesn't have to choose "Forget This Device" each time after the
> firmware upgrade. Otherwise, our end user has to "Forget This Device"
> and re-pair because the pairing info can't be found in the Linux
> device. We also set the GATT cache as "no" in
> "/etc/bluetooth/main.conf". Then the mobile app won't crash when there
> is any "service changed" such as adding notification to some existing
> characteristics.

But the cache only applies to client, service changed is for the
server not sure why your mobile would be crashing with that, or is it
disabling ServiceChanged indications with that? If there is no
indication that would explain why the services are not updated since
the mobile OS won't notice any changes on the database.

> We organize our characteristics under the services. There are 10
> services on the Linux device. Each service has 5 to 10
> characteristics. However, we found a new problem recently. The problem
> is: the first 8 services are fine. But the last one or two services
> only have the service UUID listed in nRF or our mobile app. There are
> no characteristics showing up under these one or two services. This
> caused our mobile app can't read the characteristics data under these
> problematic services. I checked the nRF. It's the same thing. nRF only
> shows the last one or two services with the service UUIDs. There are
> no characteristics listed under those 2 services.
>
> In order to fix this issue, we have to do these(let's call it "The Steps"):
> - Remove the "/var/lib/bluetooth" folder from the Linux system
> - Restart our BlueZ based service in Python in the Linux system
> - Choose "Forget This Device" on the iPhone. After this operation, the
> "/var/lib/bluetooth" is generated in the Linux device.
> - Connect to the device from our mobile app or from nRF. We can see
> all of the 10 services in the list. Each characteristic under the
> service can be seen.
> - We are able to read the data by using our mobile app or by using nRF
>
> I compared the files in the "/var/lib/bluetooth" folder. As we
> disabled the GATT cache, there is no "cache" folder. There are only 2
> files in the folder. Here is the folder structure:
> /var/lib/bluetooth:
>     |
>     +----00:11:22:33:44:55/
>         |
>         +----6C:92:11:87:11:25/
>             |
>             +----attributes
>             +----info
>
> I kept one copy of the files after the firmware upgrade. I also kept a
> copy of the files after the folder was re-generated. I compared the
> file "attributes" and "info". For the attributes, they are the same.
> For the "info" file, there are only 3 differences:
> [General]
> Name=PhoneX
> . . .
>
> [SlaveLongTermKey]
> Key=252256E19E26F3ED9FD0B99B7B5B0193
> . . .
>
> [LinkKey]
> Key=1B593296571E2C48CF6952E60395E304
> . . .
>
>
> I don't think these differences could cause the issue. But the fact
> is, if I delete the "/var/lib/bluetooth" folder and go thru "The
> Steps" above, the problem will be gone. All of the services will have
> their characteristics showing up in nRF. The data can be read from the
> characteristics. This means the folder "/var/lib/bluetooth" is related
> to the issue. But I don't know why.
>
> Here is also another thing. I subscribed to the "PropertiesChanged"
> signal. In the callback function "properties_changed", I print out the
> "changed". Here is the code to subscribe the "PropertiesChanged":
>
>         bus.add_signal_receiver(
>             properties_changed,
>             dbus_interface="org.freedesktop.DBus.Properties",
>             signal_name="PropertiesChanged",
>             arg0="org.bluez.Device1",
>             path_keyword="path",
>         )
>
> If the folder "/var/lib/bluetooth" is removed and go thru "The Steps",
> I saw the log like this:
> dbus.Dictionary({dbus.String('UUIDs'):
> dbus.Array([dbus.String('00000000-deca-fade-deca-deafdecacafe'),
> dbus.String('00001000-0000-1000-8000-00805f9b34fb'),
> dbus.String('0000110a-0000-1000-8000-00805f9b34fb'),
> dbus.String('0000110c-0000-1000-8000-00805f9b34fb'),
> dbus.String('0000110e-0000-1000-8000-00805f9b34fb'),
> dbus.String('00001116-0000-1000-8000-00805f9b34fb'),
> dbus.String('0000111f-0000-1000-8000-00805f9b34fb'),
> dbus.String('0000112f-0000-1000-8000-00805f9b34fb'),
> dbus.String('00001132-0000-1000-8000-00805f9b34fb'),
> dbus.String('00001200-0000-1000-8000-00805f9b34fb'),
> dbus.String('00001800-0000-1000-8000-00805f9b34fb'),
> dbus.String('00001801-0000-1000-8000-00805f9b34fb'),
> dbus.String('00001805-0000-1000-8000-00805f9b34fb'),
> dbus.String('0000180a-0000-1000-8000-00805f9b34fb'),
> dbus.String('0000180f-0000-1000-8000-00805f9b34fb'),
> dbus.String('02030302-1d19-415f-86f2-22a2106a0a77'),
> dbus.String('7905f431-b5ce-4e99-a40f-4b1e122d00d0'),
> dbus.String('89d3502b-0f36-433a-8ef4-c502ad55f8dc'),
> dbus.String('9fa480e0-4967-4542-9390-d343dc5d04ae'),
> dbus.String('d0611e78-bbb4-4591-a5f8-487910ae4366')],
> signature=dbus.Signature('s'), variant_level=1),
> dbus.String('ServicesResolved'): dbus.Boolean(True, variant_level=1)},
> signature=dbus.Signature('sv'))
>
> If I check the log after the firmware is upgraded without deleting the
> "/var/lib/bluetooth" folder, the log looks like this:
> dbus.Dictionary({dbus.String('ServicesResolved'): dbus.Boolean(True,
> variant_level=1)}, signature=dbus.Signature('sv'))
>
> As we can see, they are different. Is it something to do with D-Bus?
>
> We understand that if we don't carry over the "/var/lib/bluetooth"
> folder, then there is no this issue. But our end user will have to
> choose "Forget This Device" each time after the firmware is upgraded.
> Otherwise, the end user can't connect to the Linux device because the
> pairing info can't be found. Is there a way to fix this issue? Namely,
> is there a way to keep the pairing info and also avoid this issue?

This sounds like ServiceChanged is not being properly propagated when
you do the firmware update, do you have ServiceChanged entry on the
storage:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/settings-storage.txt#n321

Is there any indication on btmon when you first connect after doing
the firmware update?

-- 
Luiz Augusto von Dentz