Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 2 Oct 2019 15:31:22 +0200
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ v2] mesh: Fix IV Recovery procedure when IV Update
 is in progress
Message-ID: <20191002133122.xha64n3el4klliul@mlowasrzechonek2133>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20190909192509.15007-1-michal.lowas-rzechonek@silvair.com>
 <547a20d9ff42c6b404bfc646812a243cc2469708.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <547a20d9ff42c6b404bfc646812a243cc2469708.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 10/01, Gix, Brian wrote:
> The problem, I think, is using the iv_upd_state (which we need to do 
> IV Index recovery) as a proxy for the actual state of the IVU bit.

Agreed. The IV Recovery flag should be tracked separately from IV
Update state.

FYI:

We ended up implementing two separate state machines to process IV
Update procedure: one for 'not synced' and one for 'synced' operation.

Node starts in 'not synced' machine and moves to 'synced' when it
receives its first SNB. The move is one-way, so it's not possible to
move from 'synced' back to 'not synced' without resetting the node.

Both machines are fairly simple and nearly identical... but moving from
'not synced' to 'synced' is far from trivial.

In the end, the whole machinery is rather complex. Reflecting this
approach in BlueZ would require quite an invasive patchset, essentially
reworking the whole IV Update logic.

I'm going to try to document the whole solution and get back to you.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND