Linux bluetooth development
 help / color / mirror / Atom feed
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
Date: Tue, 14 Jan 2020 17:53:47 +0100	[thread overview]
Message-ID: <20200114165347.62egqps6uejw33a4@kynes> (raw)
In-Reply-To: <73e50268c7a5289a20adc8cffc3de2e04ef93acd.camel@intel.com>

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

      reply	other threads:[~2020-01-14 16:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 11:49 [PATCH 1/2] mesh: Add sequence nr getter to the doc Jakub Witowski
2020-01-14 11:49 ` [PATCH 2/2] mesh: Add sequence nr getter code Jakub Witowski
2020-01-14 14:50 ` [PATCH 1/2] mesh: Add sequence nr getter to the doc Gix, Brian
2020-01-14 15:40   ` Michał Lowas-Rzechonek
2020-01-14 16:39     ` Gix, Brian
2020-01-14 16:53       ` michal.lowas-rzechonek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200114165347.62egqps6uejw33a4@kynes \
    --to=michal.lowas-rzechonek@silvair.com \
    --cc=brian.gix@intel.com \
    --cc=inga.stotland@intel.com \
    --cc=jakub.witowski@silvair.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox