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>
 <CAO1O6sdke-2J=eYHS2SoG83v-hMJDBu-gasufJYDyHK+1R+w5g@mail.gmail.com>
 <CH2PR14MB3658759A2701FB52A2D6573BE6E50@CH2PR14MB3658.namprd14.prod.outlook.com>
 <CAO1O6sfwcEswTkuuntoBM_S5oFkQv7mCP1GH8Z0S0vgHk2Bp5A@mail.gmail.com>
In-Reply-To: <CAO1O6sfwcEswTkuuntoBM_S5oFkQv7mCP1GH8Z0S0vgHk2Bp5A@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Wed, 4 Mar 2020 10:36:22 -0800
Message-ID: <CABBYNZ+2v5Z05dSD+TrzioGYVWugZJGpBnq+2M=MO-smuVgXbA@mail.gmail.com>
Subject: Re: Get negotiated ATT MTU?
To:     Emil Lenngren <emil.lenngren@gmail.com>
Cc:     Jamie Mccrae <Jamie.Mccrae@lairdconnect.com>,
        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 Emil,

On Wed, Mar 4, 2020 at 7:56 AM Emil Lenngren <emil.lenngren@gmail.com> wrot=
e:
>
> Hi,
>
> Den ons 4 mars 2020 kl 11:55 skrev Jamie Mccrae <Jamie.Mccrae@lairdconnec=
t.com>:
> >
> > Hi,
> > > It should be fine also if the remote end sends an Exchange MTU reques=
t
> > > 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).
> > >
> > > Let me know if you think I've missed some edge case...
> >
> > In the core specification 5.2 volume 3 part A, there is a command, L2CA=
P_CREDIT_BASED_RECONFIGURE_REQ, which allows for the MTU to be changed afte=
r it has been established. This requires an enhanced ATT service however, b=
ut it means that the initial MTU is subject to change.
>
> I just read the L2CAP/ATT/GATT parts in the new spec. Is EATT
> implemented yet for the dbus-api, and will it affect the API? Anyway,
> for EATT it's a requirement that the MTU can only increase, never
> decrease, which shouldn't cause issues for apps. But change my "ATT
> MTU exchanged" property name proposal to "Initial ATT MTU exchanged"
> then, if waiting for the ServicesResolved wouldn't be enough, and set
> it true immediately if EATT is used and after an Exchange MTU
> procedure for unenhanced ATT. Then update the ATT MTU property when
> the MTU is increased.

It completely transparent to D-Bus, so if we do expose the MTU it
should probably be reporting the biggest MTU of all connected channel,
while it is possible to reconfigre the MTU with
L2CAP_CREDIT_BASED_RECONFIGURE_REQ I doubt we would be exposing this
sort of operation to applications, we have to keep in mind multiple
application can request a change for their own needs so like Exchange
MTU bluetoothd will be taking care of setting the MTU, that said with
EATT incoming and outgoing MTUs don't need to be symmetric like the
unenhanced bearer.

--=20
Luiz Augusto von Dentz