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:   Thu, 29 Aug 2019 11:59:51 +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] mesh: Log D-Bus method call errors
Message-ID: <20190829095951.nzzqqhgvblhogf4e@mlowasrzechonek2133>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20190820075654.2195-1-michal.lowas-rzechonek@silvair.com>
 <685bc703108f5329b861f5c5f87301b44bddd8e0.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <685bc703108f5329b861f5c5f87301b44bddd8e0.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 08/28, Gix, Brian wrote:
> On Tue, 2019-08-20 at 09:56 +0200, Michał Lowas-Rzechonek wrote:
> > If a system is misconfigured, mesh daemon might not have permissions to
> > call application methods.
> >
> > This patch causes mesh daemon to log such errors, instead of failing
> > silently.
>
> Some of these Replies for error checking are warranted, I think...
> Particularily when there is required information that needs to be sent
> to the Application during Provisioning, for instance.
>
> But sometimes we expect the application to be "away" for normal
> reasons (it is intended as a foreground app, for instance) where I am
> not sure we want to require the response... For instance the method
> calls in model.c that occur when a remote node has sent a message.

Yes, these calls were my primary concern here.

Note that D-Bus calls do *not* happen if the application is not attached
(node->owner is NULL).

> The Non-Reply version of send (towards the apps) was actually a design
> decision, since we don't want the *daemon* to exhast d-bus resources,
> depending on replies from Apps that are ignoring the messages we are
> sending.
>
> This could negatively impact the daemon's ability to
> interact with perhaps better behaved applications.  I think every
> reply required message persists for up to 30 seconds.

True.

Since most of the application-side methods do not return anything (and
rightly so, because "Any discrete OTA message might be lost"), the
application is free to do whatever is pleases with the payload,
including dropping it.

Still, I think that the none of the call handlers on the application
side should *ever* return errors/timeouts over D-Bus.

I'm arguing that such an application is misbehaving, so it probably
should be promptly detached. That would protect the daemon.

> I think our rule of thumb should be requiring a response when the
> daemon needs to know that the App has successfully handled critical
> information so for instance YES for:
>
> AddNodeComplete()
> JoinComplete()
> RequestProvData()

Agreed.

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