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;
To:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Cc:     "Gix, Brian" <brian.gix@intel.com>,
        "Stotland, Inga" <inga.stotland@intel.com>
From:   "Michael N. Moran" <mike@mnmoran.org>
Subject: mesh: Key Refresh procedure does not finalize AppKeys
Message-ID: <1a29717a-5c89-37d3-7fdb-dceeae33bee5@mnmoran.org>
Date:   Sat, 2 Jan 2021 16:01:33 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Greetings meshers,

I am testing a BlueZ mesh configuration client that performs the Key Refresh procedure.

Key Refresh works splendidly for NetKeys.

Key Refresh also works well for AppKeys located on actual remote nodes.

However, when updating the AppKeys for (what I will call) "virtual"[1] (those nodes that execute on the same host as the configuration client), the final transition back to Phase 0 doesn't take effect after returning to Phase 0 unless I restart bluetooth-meshd.

Apparently, the persistence/data-base is updated correctly since the proper state is restored after a restart of the daemon.

I suspect that somewhere in the path that begins in mesh/net.c with the function key_refresh_finish() there should be a place where the app_keys are iterated, updating the state of those AppKeys that belong to the subnet and have been updated. The update would involve copying the new_key to the "old" key field.

I am using a relatively new version of BlueZ, and the lastest version of key_refresh_finish() looks unchanged.

Am I missing something?

Thanks,
mike

[1] I use the term "virtual" to avoid confusion with the term "local" that is used in the documentation to refer to something else that is not clearly defined to me.