Skip to content

Conversation

devgianlu
Copy link

This PR exposes the MTU by reading it from the options of ReadValue and WriteValue. The downside of this approach is that there's no way to know the MTU if no reads and no writes have been made, but one could argue that it's not needed then. The D-Bus API doesn't seem to provide other ways to get the MTU anyways.

@om26er
Copy link

om26er commented Sep 19, 2025

I will try that PR and see if that works for me. I think I can settle for a micro-fork till a similar functionality lands upstream

Copy link
Member

@aykevl aykevl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see the comment below. I don't think this is the right place to add GetMTU since multiple devices (with different MTUs) can use a device at the same time so you don't know whether the MTU value is even the right value.

Comment on lines +186 to +189
// MTU returns the exchanged MTU value, or zero if not available.
func (c *Characteristic) MTU() int {
return c.char.mtu
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The MTU is, as far as I know, the property of a connection. A characteristic is local, and can be read/written from multiple connected devices. So it doesn't make much sense to expose it as part of Characteristic.
A better place would be bluetooth.Device (though I'm not sure BlueZ exposes the MTU like that).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants