DBUS API: Retrieve current MTU used by remote device

DBUS API: Retrieve current MTU used by remote device

[Olivier MARTIN]

Hi all,
I am writing a GATT server (and also a GATT client) using Bluez DBUS 
API. I looked into the Bluez DBUS API documentation but I have not found 
a way to retrieve the MTU size used for the connection between Bluez and 
a Bluetooth device.

Would a MTU property have a place in 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt?

I found some code to retrieve MTU using L2CAP. Is it the way to go?

Thanks in advance,
Olivier

Re: DBUS API: Retrieve current MTU used by remote device

[Felix Schulthess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all, dear Oliver,

On 05.07.2017 00:45, Olivier MARTIN wrote:

> I looked into the Bluez DBUS API documentation but I have not found
> a way to retrieve the MTU size used for the connection between
> Bluez and a Bluetooth device.

I am also trying to solve this Problem. Cf. my mail earlier on this
list. I suppose that you, Oliver, did not receive it, so I quote:

> I am trying to figure out the MTU of a BLE connection while it is 
> active. If I understand the Core Specification correctly, this can 
> be accomplished with the "Exchange MTU Request" as specified in
> Vol. 3, Part F, Section 3.4.2.
> 
> 1. I know one can send HCI commands with the hcitool. Is it also 
> possible to issue the request specified above using any of the 
> existing hciconfig, hcitool, hciXXX tools to find the MTU?
> 
> 2. There is a connection of which I know that its MTU is 512.
> Still, running 'hciconfig hci0 dev' reports 'ACL MTU: 310:10'. Why
> is that so?

If you figure out how to determine the MTU, I would definitely be
interested. Keep me (i.e. the list) posted.

Best, Felix
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE1nG8hohXK+pQzdzfeVlSCSL32xIFAllcmOMACgkQeVlSCSL3
2xI4dA/+PNrN3gZRe4eC2ufPPlYlQmqI/PymTZzUG9PCeFyA48kKFpnyjkTEccnQ
yuFkgeY4Yin3yxAtXuTNVv8zNpD74jg7s6TzQddKwevDV58KjbhiI1wDzVMTVmKE
L7tEr0MDJmHVXhSiF3teiu6ucC1lMSzoSww8/6j/FQVHbzZ5IAoYGx3QxDWRBw3P
BLxG8FQOqcpx8yC31q1LCEJ1RGtPkV9IN/uCbO4lfNyx3A9CEHI9ZNXuIgwxAChh
6n1Yik7JE7bE84G2ayaGYKQiOZGaCsnPTJINpFpIYGr1Pncy001IFgW4EoWKgCez
XHyB/ILIJVEHQ/vV/RA9VhEPuvnCFl05Lk2LdOz7NYTIdpeZUuNSm5ZGedmjA0bu
9Ip+h6I30aUY62uCq2ilnar/cbkaBL4WTbUucUrhG6AgUcVCahNB/M701xeAvp+e
Jj5dhNUDerG29uSwCWJpWVTYSvBHp/ZCu9/XKI84xCX42hbL2+Ucc3zYAJT5DLAu
QM172bxkr/kOoXJRy1z7i6nEU84dwODirgMROhZICGZRWE+stWxWs0GraMaFsapU
GK4X3T/cQLfnSZffENK8her9+aOxxZIQ0W8C6IYOuPTHw+8TxfIb1lC1xro1wg8I
Dn6ImMjVXznM/EIc56sEIM8ueZOfarxQPUSjOiYjH8zyA5YNTJA=
=6SAE
-----END PGP SIGNATURE-----

Re: DBUS API: Retrieve current MTU used by remote device

[Luiz Augusto von Dentz]

Hi,

On Wed, Jul 5, 2017 at 10:44 AM, Felix Schulthess
<felix.schulthess@scs.ch> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Dear all, dear Oliver,
>
> On 05.07.2017 00:45, Olivier MARTIN wrote:
>
>> I looked into the Bluez DBUS API documentation but I have not found
>> a way to retrieve the MTU size used for the connection between
>> Bluez and a Bluetooth device.
>
> I am also trying to solve this Problem. Cf. my mail earlier on this
> list. I suppose that you, Oliver, did not receive it, so I quote:

Usually you don't need to know the ATT MTU size since method like
WriteValue will fragment the data if necessary, in case of server the
prepare writes will also be reassembled before pushed over D-Bus.

For byte stream emulation please check the set that introduces
AcquireWrite and AcquireNotify:

[PATCH v2 00/10] gatt: Add AcquireWrite and AcquireNotify

>> I am trying to figure out the MTU of a BLE connection while it is
>> active. If I understand the Core Specification correctly, this can
>> be accomplished with the "Exchange MTU Request" as specified in
>> Vol. 3, Part F, Section 3.4.2.
>>
>> 1. I know one can send HCI commands with the hcitool. Is it also
>> possible to issue the request specified above using any of the
>> existing hciconfig, hcitool, hciXXX tools to find the MTU?
>>
>> 2. There is a connection of which I know that its MTU is 512.
>> Still, running 'hciconfig hci0 dev' reports 'ACL MTU: 310:10'. Why
>> is that so?
>
> If you figure out how to determine the MTU, I would definitely be
> interested. Keep me (i.e. the list) posted.

These are HCI buffer sizes, they have nothing to do with MTU in ATT/GATT.

Re: DBUS API: Retrieve current MTU used by remote device

[Olivier MARTIN]

Thanks Luiz for the answer, but I am guessing WriteValue() uses Long 
Write. But it looks like not all BLE devices support Long Read/Write 
(including Bluez until recently - v5.39 - April 2016). It also seems 
some/all(?) Android devices do not support it.

I did not find this information but is a device that does not support 
Long Write; would the application still receive GATT packets sent by 
Long Write in a defragmented manner?

The workaround often uses is to leave the GATT server fragmenting itself 
the packets to send to the GATT client with an arbitrary packet length 
value. Knowing the MTU uses between the two GATT devices could improve 
the throughput.

Re: DBUS API: Retrieve current MTU used by remote device

[Luiz Augusto von Dentz]

Hi Olivier,

On Tue, Jul 11, 2017 at 1:54 PM, Olivier MARTIN <olivier@labapart.com> wrot=
e:
> Thanks Luiz for the answer, but I am guessing WriteValue() uses Long Writ=
e.
> But it looks like not all BLE devices support Long Read/Write (including
> Bluez until recently - v5.39 - April 2016). It also seems some/all(?)
> Android devices do not support it.

I wouldn't call recently a more than one year only release and I guess
the versions that don't support, and I though Long Write is mandatory
for the server at least for the complete server:

C.4: Mandatory IF GATT 1/4 =E2=80=9CComplete GATT Server=E2=80=9D is suppor=
ted,
otherwise Optional.

or are you talking about Reliable Writes?

> I did not find this information but is a device that does not support Lon=
g
> Write; would the application still receive GATT packets sent by Long Writ=
e
> in a defragmented manner?

I guess the remaining bytes over the MTU would not be sent since that
would require Prepare Write operation which I guess fail with such
devices and since regular Write Request don't have an offset we cannot
continue sending.

> The workaround often uses is to leave the GATT server fragmenting itself =
the
> packets to send to the GATT client with an arbitrary packet length value.
> Knowing the MTU uses between the two GATT devices could improve the
> throughput.

I guess you mean the GATT server will not be able to reassemble thus
you send in chunks as big as the MTU, but this presumes there is
something in the data payload that is doing sar, so a protocol on top
of GATT.

But be aware that most OSes don't protect against multiple clients
writing to the same attribute, not to mention there can be quite big
latencies since GATT has a 30 seconds timeout for each request which
is why usually Write Without Response procedure is used with such
operations.

If you care about throughput then using D-Bus to pipe data is probably
very inefficient, L2CAP CoC would probably be the best solution to
something like a serial port emulation over LE, but sadly Android and
iOS still don't support that.

--=20
Luiz Augusto von Dentz

Re: DBUS API: Retrieve current MTU used by remote device

[Olivier MARTIN]

Hi Luiz,

Ubuntu 16.04 LTS is shipped with bluez v5.37. You could argue Bluez 
v5.37 does not officially support GATT over DBus as the support is still 
experimental which is true. And because v5.37 does not support GATT Long 
Write, developers should not use Bluez prior to v5.42 (date when GATT 
D-Bus API is marked as not experimental anymore).

As the GATT client might also send packet longer than 20 bytes, the 
client also needs to support Long Read/Write (same as GATT server).
 From my quick search, it looks Long Read/Write support is not well 
supported by all GATT server/client. I do not know whether it is a 
correct assumption or developers are not aware of its support.

At the moment I am using a protocol on top of GATT to send my payload in 
chunk. I sometimes send payloads as large as 200 bytes. By sending 19 
bytes (+ 1 bytes for the application protocol to support chunk) I need 
11 GATT characteristic writes while I could send only 1 packet if I knew 
the ATT MTU could have been increased to 203 bytes or more.
Throughput is not critical but it has a high importance in my use case 
(Human Machine interface).

By increasing my hardcoded payload from 20 bytes to 200 bytes (because I 
know the negociated ATT MTU is 512 bytes), my application test time 
execution dereases from 32sec to 11sec. If I knew the ATT MTU (for 
instance from D-Bus Bluez), I could replace the hardcoded value by the 
negociated one.

If I had some confidence Long Read/Write feature was well supported, I 
will be happy to use it. But I am worry it is not - but I could be 
wrong. What do you think?


On 11.07.2017 15:01, Luiz Augusto von Dentz wrote:
> Hi Olivier,
> 
> On Tue, Jul 11, 2017 at 1:54 PM, Olivier MARTIN <olivier@labapart.com> 
> wrote:
>> Thanks Luiz for the answer, but I am guessing WriteValue() uses Long 
>> Write.
>> But it looks like not all BLE devices support Long Read/Write 
>> (including
>> Bluez until recently - v5.39 - April 2016). It also seems some/all(?)
>> Android devices do not support it.
> 
> I wouldn't call recently a more than one year only release and I guess
> the versions that don't support, and I though Long Write is mandatory
> for the server at least for the complete server:
> 
> C.4: Mandatory IF GATT 1/4 “Complete GATT Server” is supported,
> otherwise Optional.
> 
> or are you talking about Reliable Writes?
> 
>> I did not find this information but is a device that does not support 
>> Long
>> Write; would the application still receive GATT packets sent by Long 
>> Write
>> in a defragmented manner?
> 
> I guess the remaining bytes over the MTU would not be sent since that
> would require Prepare Write operation which I guess fail with such
> devices and since regular Write Request don't have an offset we cannot
> continue sending.
> 
>> The workaround often uses is to leave the GATT server fragmenting 
>> itself the
>> packets to send to the GATT client with an arbitrary packet length 
>> value.
>> Knowing the MTU uses between the two GATT devices could improve the
>> throughput.
> 
> I guess you mean the GATT server will not be able to reassemble thus
> you send in chunks as big as the MTU, but this presumes there is
> something in the data payload that is doing sar, so a protocol on top
> of GATT.
> 
> But be aware that most OSes don't protect against multiple clients
> writing to the same attribute, not to mention there can be quite big
> latencies since GATT has a 30 seconds timeout for each request which
> is why usually Write Without Response procedure is used with such
> operations.
> 
> If you care about throughput then using D-Bus to pipe data is probably
> very inefficient, L2CAP CoC would probably be the best solution to
> something like a serial port emulation over LE, but sadly Android and
> iOS still don't support that.

http://labapart.com

Re: DBUS API: Retrieve current MTU used by remote device

[Luiz Augusto von Dentz]

Hi Olivier,

On Tue, Jul 11, 2017 at 7:31 PM, Olivier MARTIN <olivier@labapart.com> wrot=
e:
> Hi Luiz,
>
> Ubuntu 16.04 LTS is shipped with bluez v5.37. You could argue Bluez v5.37
> does not officially support GATT over DBus as the support is still
> experimental which is true. And because v5.37 does not support GATT Long
> Write, developers should not use Bluez prior to v5.42 (date when GATT D-B=
us
> API is marked as not experimental anymore).
>
> As the GATT client might also send packet longer than 20 bytes, the clien=
t
> also needs to support Long Read/Write (same as GATT server).
> From my quick search, it looks Long Read/Write support is not well suppor=
ted
> by all GATT server/client. I do not know whether it is a correct assumpti=
on
> or developers are not aware of its support.
>
> At the moment I am using a protocol on top of GATT to send my payload in
> chunk. I sometimes send payloads as large as 200 bytes. By sending 19 byt=
es
> (+ 1 bytes for the application protocol to support chunk) I need 11 GATT
> characteristic writes while I could send only 1 packet if I knew the ATT =
MTU
> could have been increased to 203 bytes or more.
> Throughput is not critical but it has a high importance in my use case
> (Human Machine interface).
>
> By increasing my hardcoded payload from 20 bytes to 200 bytes (because I
> know the negociated ATT MTU is 512 bytes), my application test time
> execution dereases from 32sec to 11sec. If I knew the ATT MTU (for instan=
ce
> from D-Bus Bluez), I could replace the hardcoded value by the negociated
> one.

So it is 22 sec of round trips, not only over the air but also D-Bus
message round trips between processes.

> If I had some confidence Long Read/Write feature was well supported, I wi=
ll
> be happy to use it. But I am worry it is not - but I could be wrong. What=
 do
> you think?

If you control both GATT server and client why not use write without
response and notifications, then you can use AcquireWrite and
AcquireNotify and write/read using the given fd and MTU.

>
>
> On 11.07.2017 15:01, Luiz Augusto von Dentz wrote:
>>
>> Hi Olivier,
>>
>> On Tue, Jul 11, 2017 at 1:54 PM, Olivier MARTIN <olivier@labapart.com>
>> wrote:
>>>
>>> Thanks Luiz for the answer, but I am guessing WriteValue() uses Long
>>> Write.
>>> But it looks like not all BLE devices support Long Read/Write (includin=
g
>>> Bluez until recently - v5.39 - April 2016). It also seems some/all(?)
>>> Android devices do not support it.
>>
>>
>> I wouldn't call recently a more than one year only release and I guess
>> the versions that don't support, and I though Long Write is mandatory
>> for the server at least for the complete server:
>>
>> C.4: Mandatory IF GATT 1/4 =E2=80=9CComplete GATT Server=E2=80=9D is sup=
ported,
>> otherwise Optional.
>>
>> or are you talking about Reliable Writes?
>>
>>> I did not find this information but is a device that does not support
>>> Long
>>> Write; would the application still receive GATT packets sent by Long
>>> Write
>>> in a defragmented manner?
>>
>>
>> I guess the remaining bytes over the MTU would not be sent since that
>> would require Prepare Write operation which I guess fail with such
>> devices and since regular Write Request don't have an offset we cannot
>> continue sending.
>>
>>> The workaround often uses is to leave the GATT server fragmenting itsel=
f
>>> the
>>> packets to send to the GATT client with an arbitrary packet length valu=
e.
>>> Knowing the MTU uses between the two GATT devices could improve the
>>> throughput.
>>
>>
>> I guess you mean the GATT server will not be able to reassemble thus
>> you send in chunks as big as the MTU, but this presumes there is
>> something in the data payload that is doing sar, so a protocol on top
>> of GATT.
>>
>> But be aware that most OSes don't protect against multiple clients
>> writing to the same attribute, not to mention there can be quite big
>> latencies since GATT has a 30 seconds timeout for each request which
>> is why usually Write Without Response procedure is used with such
>> operations.
>>
>> If you care about throughput then using D-Bus to pipe data is probably
>> very inefficient, L2CAP CoC would probably be the best solution to
>> something like a serial port emulation over LE, but sadly Android and
>> iOS still don't support that.
>
>
> http://labapart.com



--=20
Luiz Augusto von Dentz

Re: DBUS API: Retrieve current MTU used by remote device

[Olivier MARTIN]

Hi Luiz,

On 13.07.2017 13:18, Luiz Augusto von Dentz wrote:
> Hi Olivier,
> 
> On Tue, Jul 11, 2017 at 7:31 PM, Olivier MARTIN <olivier@labapart.com> 
> wrote:
>> Hi Luiz,
>> 
>> Ubuntu 16.04 LTS is shipped with bluez v5.37. You could argue Bluez 
>> v5.37
>> does not officially support GATT over DBus as the support is still
>> experimental which is true. And because v5.37 does not support GATT 
>> Long
>> Write, developers should not use Bluez prior to v5.42 (date when GATT 
>> D-Bus
>> API is marked as not experimental anymore).
>> 
>> As the GATT client might also send packet longer than 20 bytes, the 
>> client
>> also needs to support Long Read/Write (same as GATT server).
>> From my quick search, it looks Long Read/Write support is not well 
>> supported
>> by all GATT server/client. I do not know whether it is a correct 
>> assumption
>> or developers are not aware of its support.
>> 
>> At the moment I am using a protocol on top of GATT to send my payload 
>> in
>> chunk. I sometimes send payloads as large as 200 bytes. By sending 19 
>> bytes
>> (+ 1 bytes for the application protocol to support chunk) I need 11 
>> GATT
>> characteristic writes while I could send only 1 packet if I knew the 
>> ATT MTU
>> could have been increased to 203 bytes or more.
>> Throughput is not critical but it has a high importance in my use case
>> (Human Machine interface).
>> 
>> By increasing my hardcoded payload from 20 bytes to 200 bytes (because 
>> I
>> know the negociated ATT MTU is 512 bytes), my application test time
>> execution dereases from 32sec to 11sec. If I knew the ATT MTU (for 
>> instance
>> from D-Bus Bluez), I could replace the hardcoded value by the 
>> negociated
>> one.
> 
> So it is 22 sec of round trips, not only over the air but also D-Bus
> message round trips between processes.
> 
>> If I had some confidence Long Read/Write feature was well supported, I 
>> will
>> be happy to use it. But I am worry it is not - but I could be wrong. 
>> What do
>> you think?
> 
> If you control both GATT server and client why not use write without
> response and notifications, then you can use AcquireWrite and
> AcquireNotify and write/read using the given fd and MTU.
> 

I can see AcquireWrite and AcquireNotify are marked as experimental in 
the current Bluez. So it means it will not be supported by current 
distributions.

Unfortunately I do not control the GATT server and client. My project is 
a software protocol that I aim to deploy on various Bluetooth software 
stack/firmware from various vendors (Bluez, Windows, Apple, Android + 
different firmware vendor, MCU such as Nordic).
I am a bit concern if I use Long Write/Read, I will spend a lot of time 
supporting Bluetooth stack variations.

I would be happy to use Long Write/Read if the feature could be probed 
to know if it is supported by the BLE device and fallback to the 
application protocol if not supported. But I guess by specification, it 
is assumed the feature is always be present and supported.
I am considering to use my application packet protocol by default and 
use a mechanism to let know the GATT server and client Long Write/Read 
are supported by both devices to then switch to use them.

Exposing the ATT MTU through Bluez D-BUS API would solve my issue even 
if it is a workaround in term of GATT specification. For diagnostic 
purpose, it might still be helpful to have the MTU exposed in D-BUS API.
I am happy to have a try to add the support for ATT MTU to Bluez D-BUS 
Device API myself if you think it is feasible and the patches will be 
accepted (obviously after being approved on the mailing-list).

Re: DBUS API: Retrieve current MTU used by remote device

[Luiz Augusto von Dentz]

Hi Olivier,

On Fri, Jul 14, 2017 at 1:47 AM, Olivier MARTIN <olivier@labapart.com> wrote:
> Hi Luiz,
>
> On 13.07.2017 13:18, Luiz Augusto von Dentz wrote:
>>
>> Hi Olivier,
>>
>> On Tue, Jul 11, 2017 at 7:31 PM, Olivier MARTIN <olivier@labapart.com>
>> wrote:
>>>
>>> Hi Luiz,
>>>
>>> Ubuntu 16.04 LTS is shipped with bluez v5.37. You could argue Bluez v5.37
>>> does not officially support GATT over DBus as the support is still
>>> experimental which is true. And because v5.37 does not support GATT Long
>>> Write, developers should not use Bluez prior to v5.42 (date when GATT
>>> D-Bus
>>> API is marked as not experimental anymore).
>>>
>>> As the GATT client might also send packet longer than 20 bytes, the
>>> client
>>> also needs to support Long Read/Write (same as GATT server).
>>> From my quick search, it looks Long Read/Write support is not well
>>> supported
>>> by all GATT server/client. I do not know whether it is a correct
>>> assumption
>>> or developers are not aware of its support.
>>>
>>> At the moment I am using a protocol on top of GATT to send my payload in
>>> chunk. I sometimes send payloads as large as 200 bytes. By sending 19
>>> bytes
>>> (+ 1 bytes for the application protocol to support chunk) I need 11 GATT
>>> characteristic writes while I could send only 1 packet if I knew the ATT
>>> MTU
>>> could have been increased to 203 bytes or more.
>>> Throughput is not critical but it has a high importance in my use case
>>> (Human Machine interface).
>>>
>>> By increasing my hardcoded payload from 20 bytes to 200 bytes (because I
>>> know the negociated ATT MTU is 512 bytes), my application test time
>>> execution dereases from 32sec to 11sec. If I knew the ATT MTU (for
>>> instance
>>> from D-Bus Bluez), I could replace the hardcoded value by the negociated
>>> one.
>>
>>
>> So it is 22 sec of round trips, not only over the air but also D-Bus
>> message round trips between processes.
>>
>>> If I had some confidence Long Read/Write feature was well supported, I
>>> will
>>> be happy to use it. But I am worry it is not - but I could be wrong. What
>>> do
>>> you think?
>>
>>
>> If you control both GATT server and client why not use write without
>> response and notifications, then you can use AcquireWrite and
>> AcquireNotify and write/read using the given fd and MTU.
>>
>
> I can see AcquireWrite and AcquireNotify are marked as experimental in the
> current Bluez. So it means it will not be supported by current
> distributions.

It hasn't been released yet, but at first all API are marked experimental.

> Unfortunately I do not control the GATT server and client. My project is a
> software protocol that I aim to deploy on various Bluetooth software
> stack/firmware from various vendors (Bluez, Windows, Apple, Android +
> different firmware vendor, MCU such as Nordic).
> I am a bit concern if I use Long Write/Read, I will spend a lot of time
> supporting Bluetooth stack variations.

Read again, I did not suggest you to use Long Write, and when I said
control the server I mean control the attribute/characteristic
definition so you can define it to use write without response and
notifications since that is indicated in the characteristic
properties.

> I would be happy to use Long Write/Read if the feature could be probed to
> know if it is supported by the BLE device and fallback to the application
> protocol if not supported. But I guess by specification, it is assumed the
> feature is always be present and supported.
> I am considering to use my application packet protocol by default and use a
> mechanism to let know the GATT server and client Long Write/Read are
> supported by both devices to then switch to use them.

There is nothing to detect that Long Write is supported upfront, so
you would have to actually write to see if that works, but then again
why would like to go this way if you can use write without response
and notifications?

> Exposing the ATT MTU through Bluez D-BUS API would solve my issue even if it
> is a workaround in term of GATT specification. For diagnostic purpose, it
> might still be helpful to have the MTU exposed in D-BUS API.
> I am happy to have a try to add the support for ATT MTU to Bluez D-BUS
> Device API myself if you think it is feasible and the patches will be
> accepted (obviously after being approved on the mailing-list).

It would have the same treatment as AcquireWrite and AcquireNotify so
at the start it would probably be marked as experimental. Note that

-- 
Luiz Augusto von Dentz

Re: DBUS API: Retrieve current MTU used by remote device

[Jonah Petri]

>=20
>> Exposing the ATT MTU through Bluez D-BUS API would solve my issue =
even if it
>> is a workaround in term of GATT specification. For diagnostic =
purpose, it
>> might still be helpful to have the MTU exposed in D-BUS API.
>> I am happy to have a try to add the support for ATT MTU to Bluez =
D-BUS
>> Device API myself if you think it is feasible and the patches will be
>> accepted (obviously after being approved on the mailing-list).
>=20
> It would have the same treatment as AcquireWrite and AcquireNotify so
> at the start it would probably be marked as experimental. Note that

I have a patch for this exact need (reading the negotiated MTU), which I =
can submit later today for consideration.

Jonah=

Re: DBUS API: Retrieve current MTU used by remote device

[Olivier MARTIN]

Hi Jonah, Luiz and all,

On 14.07.2017 14:02, Jonah Petri wrote:
>> 
>>> Exposing the ATT MTU through Bluez D-BUS API would solve my issue 
>>> even if it
>>> is a workaround in term of GATT specification. For diagnostic 
>>> purpose, it
>>> might still be helpful to have the MTU exposed in D-BUS API.
>>> I am happy to have a try to add the support for ATT MTU to Bluez 
>>> D-BUS
>>> Device API myself if you think it is feasible and the patches will be
>>> accepted (obviously after being approved on the mailing-list).
>> 
>> It would have the same treatment as AcquireWrite and AcquireNotify so
>> at the start it would probably be marked as experimental. Note that
> 
> I have a patch for this exact need (reading the negotiated MTU), which
> I can submit later today for consideration.

I also started to look at adding this support this morning. But I had to 
interrupt my work. So I will be happy to have a look and review your 
patch as I have a clearer idea of the code now.

Thanks to Luiz and after doing a little break, I realised I need to 
change my application protocol to take advantage of AcquireWrite and 
AcquireNotify.
I am quite convince now I will have a better throughput using these 
methods than using my current application protocol.