Hi Tobias,
On Fri, Sep 9, 2016 at 3:27 PM, Tobias Svehagen
<tobias.svehagen@xxxxxxxxx> wrote:
> Use the default MTU until an MTU exchange has taken place and
> something else has been negotiated. If either side does not support
> MTU exchange, the connection shall continue to use this default
> value instead of the device maximum which was the previous behavior.
> ---
> src/device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/device.c b/src/device.c
> index 9586022..ea36848 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -4778,7 +4778,7 @@ bool device_attach_att(struct btd_device *dev, GIOChannel *io)
> }
>
> dev->att_mtu = MIN(mtu, BT_ATT_MAX_LE_MTU);
> - attrib = g_attrib_new(io, dev->att_mtu, false);
> + attrib = g_attrib_new(io, BT_ATT_DEFAULT_LE_MTU, false);
This is not complete right since latter on if the MTU is negotiated by
bt_gatt_client, but I remember fixing something like this:
commit 64f864173393f6e750a94b895f39119ca80b93df
Author: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>
Date: Thu Mar 12 16:18:45 2015 +0200
attrib: Fix not honoring MTU
If MTU has changed, by bt_gatt_client for example, the code should be
able to figure it out without waiting g_attrib_set_mtu to be called.
Btw, it would be good to have some logs what exactly is the scenario
where this happens.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
