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>
In-Reply-To: <CAO1O6sdGJeAKTHBVyDSUa7-Hp_ULYmfOHJEbb6=-B6xuPHvffQ@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Sat, 29 Feb 2020 22:46:46 -0800
Message-ID: <CABBYNZKtxPmTUn2fw9-dy1V9M_Pb996O6VmHkg4NrAr-=t+-4A@mail.gmail.com>
Subject: Re: Get negotiated ATT MTU?
To:     Emil Lenngren <emil.lenngren@gmail.com>
Cc:     Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Emil,

On Sat, Feb 29, 2020 at 2:13 AM Emil Lenngren <emil.lenngren@gmail.com> wrote:
>
> 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,
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 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.

-- 
Luiz Augusto von Dentz