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> <CABBYNZ+2v5Z05dSD+TrzioGYVWugZJGpBnq+2M=MO-smuVgXbA@mail.gmail.com>
In-Reply-To: <CABBYNZ+2v5Z05dSD+TrzioGYVWugZJGpBnq+2M=MO-smuVgXbA@mail.gmail.com>
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Wed, 4 Mar 2020 18:47:23 +0000
Message-ID: <CAO1O6sfWgqnduM8_UuO_1W8KjnEvoetbk6bcaA_ATFUaXLtB0w@mail.gmail.com>
Subject: Re: Get negotiated ATT MTU?
To:     Luiz Augusto von Dentz <luiz.dentz@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,

Den ons 4 mars 2020 kl 18:36 skrev Luiz Augusto von Dentz
<luiz.dentz@gmail.com>:
>
> Hi Emil,
>
> On Wed, Mar 4, 2020 at 7:56 AM Emil Lenngren <emil.lenngren@gmail.com> wr=
ote:
> >
> > Hi,
> >
> > Den ons 4 mars 2020 kl 11:55 skrev Jamie Mccrae <Jamie.Mccrae@lairdconn=
ect.com>:
> > >
> > > Hi,
> > > > It should be fine also if the remote end sends an Exchange MTU requ=
est
> > > > at the beginning of the connection since we can then immediately se=
nd
> > > > 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, L2=
CAP_CREDIT_BASED_RECONFIGURE_REQ, which allows for the MTU to be changed af=
ter it has been established. This requires an enhanced ATT service however,=
 but 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,

Is there ever any reason for one application to have more than one ATT
bearer? I thought the idea of EATT was to allow one ATT bearer per
application.

> 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,

I think it's fine that bluetoothd chooses the MTU. I don't see any
reason that the application should choose MTU (assuming bluetoothd
sets a big value).

> that said with
> EATT incoming and outgoing MTUs don't need to be symmetric like the
> unenhanced bearer.

While that is true on the L2CAP layer, it's not true on the GATT layer:

Vol 3 Part G section 5.3.1:
"The ATT_MTU for the Enhanced ATT bearer shall be set to the minimum of the
MTU field values of the two devices; these values come from the L2CAP_-
CREDIT_BASED_CONNECTION_REQ and L2CAP_CREDIT_BASED_-
CONNECTION_RSP signaling packets or the latest L2CAP_CREDIT_-
BASED_RECONFIGURE_REQ packets."

So if the peripheral sets its receive MTU to 48 and the central sets
its receive MTU to 517, then 48 will be used in both directions.

/Emil