Hi Emil, On Wed, Mar 4, 2020 at 7:56 AM Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote: > > Hi, > > Den ons 4 mars 2020 kl 11:55 skrev Jamie Mccrae <Jamie.Mccrae@xxxxxxxxxxxxxxxx>: > > > > Hi, > > > It should be fine also if the remote end sends an Exchange MTU request > > > 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, L2CAP_CREDIT_BASED_RECONFIGURE_REQ, which allows for the MTU to be changed after 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, 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. -- Luiz Augusto von Dentz
