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:   Tue, 14 Jan 2020 17:53:47 +0100
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH 1/2] mesh: Add sequence nr getter to the doc
Message-ID: <20200114165347.62egqps6uejw33a4@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
References: <20200114114914.25868-1-jakub.witowski@silvair.com>
 <1382d00407f6c7836f7983e374d6c504931f6e9e.camel@intel.com>
 <20200114154012.gixnyhceabg2lrsp@mlowasrzechonek2133>
 <73e50268c7a5289a20adc8cffc3de2e04ef93acd.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <73e50268c7a5289a20adc8cffc3de2e04ef93acd.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi,

On 01/14, Gix, Brian wrote:
> I have some serious discomfort with an API to increase sequence numbers.  On import,
> the sequence number should be part of the data being imported, so I don't see a
> direct need there to bump up the value afterwards.
> 
> Plus, we handle sequence numbers differently than many other settings in the
> system.  To prevent storage thrashing, we "Pre-Reserve" a chunk of sequence
> numbers that we store in node.json, and then real-time use these sequence
> numbers for outbound packets without having to write to storage each time
> (a power failure or other reset would then pick up after the reserved chunk).
> And then it also feeds into the IV Index update feature as well.
> 
> Giving an App the ability to arbitrarily increase it's sequence number puts
> it into conflict with the natural usage of sequence numbers, and when we request
> the IV Index Update.

Ok, I appreciate that. Let's take a look from a different angle.

As I mentioned some time ago, we're working on an automated test suite
for the daemon. We need to know the current value of sequence number to
verify payloads send to radio adapter. One can say that we're
*eventually* aiming for, is a "test mode" of sorts.

A significant part of the suite is checking the IV Update logic. As
you've seen, there was/is a fair number of issues with the current
implementation. We know from (painful) experience, that this part of the
system is notoriously difficult to implement correctly and efficiently.
One of the problems is verifying time-based behaviour.

Mesh spec actually mandates that the device shall implement the test
mode by removing state timers, but it doesn't say anything about
triggering the node to start IV Update.

So maybe we in the end we could enable SequenceNumber etc. access only
when daemon is running with a certain configuration option (either
commandline, of from the file)?

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