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;
MIME-Version: 1.0
References: <CAO1O6sdGJeAKTHBVyDSUa7-Hp_ULYmfOHJEbb6=-B6xuPHvffQ@mail.gmail.com>
 <CABBYNZKtxPmTUn2fw9-dy1V9M_Pb996O6VmHkg4NrAr-=t+-4A@mail.gmail.com>
In-Reply-To: <CABBYNZKtxPmTUn2fw9-dy1V9M_Pb996O6VmHkg4NrAr-=t+-4A@mail.gmail.com>
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Sun, 1 Mar 2020 20:16:04 +0100
Message-ID: <CAO1O6sdke-2J=eYHS2SoG83v-hMJDBu-gasufJYDyHK+1R+w5g@mail.gmail.com>
Subject: Re: Get negotiated ATT MTU?
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Luiz,

Den s=C3=B6n 1 mars 2020 kl 07:46 skrev Luiz Augusto von Dentz
<luiz.dentz@gmail.com>:
>
> Hi Emil,
>
> On Sat, Feb 29, 2020 at 2:13 AM Emil Lenngren <emil.lenngren@gmail.com> w=
rote:
> >
> > Hi. I have a feature request that the negotiated ATT MTU should be
> > exposed as a property in the org.bluez.Device1 interface.
> >
> > For some applications it's good to know or required how much data that
> > can be written / read / notified in each packet, and it's not always
> > desired or possible to use AcquireNotify / AcquireWrite.
>
> We already negotiate a fairly big MTU maximum by default, and you can
> just use AcquireWrite/AcquireNotify just to discover it and the close
> the fd immediately, so I suppose we cover much of what the feature is,

I was considering having a solution implementable by for example
Web-Bluetooth. This "workaround" wouldn't always work since it's not
guaranteed to exist a characteristic with the 'write-without-response'
or 'notify' property. I think there could also be a "race condition"
here if two apps do the same thing (although the time window is pretty
small): one app might get that the acquire operation returned "busy".
And is it even possible to use AcquireNotify/AcquiceWrite if the d-bus
runs over tcp or the programming language doesn't support d-bus file
descriptors? An ATT MTU property would be so much simpler and
straight-forward.

> except perhaps if the application requires something bellow the
> default MTU bluetoothd but that can be a problem if other application
> would start requiring their own MTU as well, so even if we introduce a
> Property that would have to be read-only

Yes! The idea was to have it read-only. It's sane to let the BT stack
negotiate (a big value on non-embedded systems like Linux/BlueZ)
immediately after the connection has been established. There should be
no reason for an application using BlueZ to negotiate a smaller MTU
than a "big" one, which BlueZ already selects.

> but there may be races if the
> application start writing/reading too fast or the remote end do
> trigger its own exchange for some reason.

It's already not possible to write anything after "Connected" has
become true but before "ServicesResolved" becomes true (I get
"org.bluez.Error.Failed: Not connected" in that case). I assume MTU is
guaranteed to have been exchanged at this point, so there shouldn't be
any problem for this case. Another possibility would also be to add a
boolean "ATT MTU exchanged" property which is set to true when the MTU
property becomes valid, if waiting for "ServicesResolved" wouldn't be
enough.

It should be fine also if the remote end sends an Exchange MTU request
at the beginning of the connection since we can then immediately send
a response and assign the MTU property without waiting for the
Exchange MTU response (that corresponds to our request).

In the case when the remote end sends a notification before it
receives our Exchange MTU request, then the MTU property would
correctly be 23 since the MTU Exchange hasn't finished yet.

The list of five rules in Bluetooth Core specification Vol 3 Part F
3.4.2.2 (ATT_EXCHANGE_MTU_RSP) should also prevent most "race
conditions".

Let me know if you think I've missed some edge case...

/Emil