MTU size incorrect on Windows

[ddomnik]

First of all, thanks for this nice BLE lib!

• bleak version: 0.21.1
• bleak-winrt version: 1.2.0
• Python version: 3.11.3
• Operating System: Windows 11 (build 22621.3007)
• Bluetooth: LMP 12.13576 (5.3)

Description

Using a NRF52 development kit, which acts as a BLE peripheral, I want to transfer data from my PC via a Write-Characteristics. The MTU size on the NRF52 is set to 247, however max_write_without_response_size returns 20.

                chrc = self.BLE_DEVICE.services.get_characteristic(BLE_CHRC_TRANSFER)
                print("MAX SIZE: ",chrc.max_write_without_response_size)

But as seen it the Wireshark logs, it seems that the correct MTU size gets transmitted. Client Rx MTU: 527 Server RX MTU: 247 (as defined)

I have also tested it on another Windows machine successfully, max_write_without_response_size returns 244 as expected.

• bleak version: 0.21.1
• bleak-winrt version: 1.2.0
• Python version: 3.10.11
• Operating System: Windows 10 (build19045.3930)
• Bluetooth: LMP 12.13054 (5.3)

Please let me know if you need more details. I wasnt sure how to collect debug logs on Windows.

[dlech]

It could be that the Bluetooth adapter (or the driver) on the "problem" computer is the one limiting the MTU.

https://bleak.readthedocs.io/en/latest/troubleshooting.html#enable-logging

explains how to enable logging.

[ddomnik]

It could be that the Bluetooth adapter (or the driver) on the "problem" computer is the one limiting the MTU.

https://bleak.readthedocs.io/en/latest/troubleshooting.html#enable-logging

explains how to enable logging.

Ah thanks, I was mistakenly using CMD instead of PS and was wondering why there are no logs 😅 ... Also on the problem computer it seems to detect the MTU size correctly in the backend. I noticed, that max_write_without_response_size does not work, but mtu_size is working fine. I can work with mtu_size. Maybe I am using max_write_without_response_size wrong?

Connect to:  F6:27:5F:34:F6:28: myDevice
2024-01-23 18:35:56,182 bleak.backends.winrt.scanner MainThread DEBUG: Received 1F:EE:46:66:32:BE: .
2024-01-23 18:35:56,288 bleak.backends.winrt.scanner MainThread DEBUG: Received 1F:EE:46:66:32:BE: .
2024-01-23 18:35:56,534 bleak.backends.winrt.scanner MainThread DEBUG: Received F6:27:5F:34:F6:28: myDevice.
2024-01-23 18:35:56,535 bleak.backends.winrt.scanner MainThread DEBUG: 2 devices found. Watcher status: <BluetoothLEAdvertisementWatcherStatus.STOPPED: 3>.
2024-01-23 18:35:56,536 bleak.backends.winrt.client MainThread DEBUG: Connecting to BLE device @ F6:27:5F:34:F6:28
2024-01-23 18:35:56,536 bleak.backends.winrt.scanner MainThread DEBUG: Received F6:27:5F:34:F6:28: .
2024-01-23 18:35:56,611 bleak.backends.winrt.client MainThread DEBUG: getting services (service_cache_mode=None, cache_mode=None)...
2024-01-23 18:35:56,750 bleak.backends.winrt.client Dummy-2 DEBUG: session_status_changed_event_handler: id: BluetoothLE#BluetoothLE70:1a:b8:28:2e:da-f6:27:5f:34:f6:28, error: <BluetoothError.SUCCESS: 0>, status: <GattSessionStatus.ACTIVE: 1>
Connected to: BleakClient, F6:27:5F:34:F6:28
- Service: Generic Attribute Profile
  - Characteristic: Service Changed uuid: 00002a05-0000-1000-8000-00805f9b34fb prop: ['indicate']
  - Characteristic: Client Supported Features uuid: 00002b29-0000-1000-8000-00805f9b34fb prop: ['read', 'write']
  - Characteristic: Database Hash uuid: 00002b2a-0000-1000-8000-00805f9b34fb prop: ['read']
- Service: Generic Access Profile
  - Characteristic: Device Name uuid: 00002a00-0000-1000-8000-00805f9b34fb prop: ['read']
  - Characteristic: Appearance uuid: 00002a01-0000-1000-8000-00805f9b34fb prop: ['read']
  - Characteristic: Peripheral Preferred Connection Parameters uuid: 00002a04-0000-1000-8000-00805f9b34fb prop: ['read']
- Service: Battery Service
  - Characteristic: Battery Level uuid: 00002a19-0000-1000-8000-00805f9b34fb prop: ['read', 'notify']
- Service: Unknown
  - Characteristic: Unknown uuid: e9ea0002-e19b-482d-9293-c7907585fc48 prop: ['read', 'write']
  - Characteristic: Unknown uuid: e9ea0003-e19b-482d-9293-c7907585fc48 prop: ['read', 'write']
BLE connected: BleakClient, F6:27:5F:34:F6:28
2024-01-23 18:35:56,867 bleak.backends.winrt.client Dummy-3 DEBUG: max_pdu_size_changed_handler: 247
show tray
[Button click]
MTU SIZE:  20
2024-01-23 18:36:04,653 bleak.backends.winrt.client MainThread DEBUG: Read Characteristic 0015 : bytearray(b'\xab')
Read response:  bytearray(b'\xab')
MTU SIZE 2:  20
MTU SIZE DEVICE:  247

        if(self.BLE_DEVICE != None):
            if(self.BLE_DEVICE.is_connected):

                service = self.BLE_DEVICE.services.get_service(BLE_SRVC_TRANSFER)
                chrc = service.get_characteristic(BLE_CHRC_TRANSFER)
                print("MTU SIZE: ",chrc.max_write_without_response_size)

                res = await self.BLE_DEVICE.read_gatt_char(chrc)
                print("Read response: ", res)

                service = self.BLE_DEVICE.services.get_service(BLE_SRVC_TRANSFER)
                chrc = service.get_characteristic(BLE_CHRC_TRANSFER)
                print("MTU SIZE 2: ",chrc.max_write_without_response_size)

                print("MTU SIZE DEVICE: ",self.BLE_DEVICE.mtu_size)

[dlech]

Thanks for the logs. This looks like a race condition where on this particular adapter/computer, the max_pdu_size_changed event is received after services are enumerated. On everything else I've seen before, this happens in the other order.

[JPHutchins]

Seeing this as well. mtu_size shows 498, which is correct, but the characteristic shows 20.

2024-03-30 18:20:21,205 bleak.backends.winrt.client MainThread DEBUG: Connecting to BLE device @ F2:0D:69:5C:11:6F
2024-03-30 18:20:21,309 bleak.backends.winrt.client MainThread DEBUG: getting services (service_cache_mode=None, cache_mode=None)...
2024-03-30 18:20:22,157 bleak.backends.winrt.client Dummy-1 DEBUG: session_status_changed_event_handler: id: BluetoothLE#BluetoothLEe0:d4:64:58:c4:91-f2:0d:69:5c:11:6f, error: <BluetoothError.SUCCESS: 0>, status: <GattSessionStatus.ACTIVE: 1>
2024-03-30 18:20:22,172 bleak.backends.winrt.client Dummy-1 DEBUG: max_pdu_size_changed_handler: 498
OK
Client MTU is 20B
client._transport._client.mtu_size=498
smp_characteristic.max_write_without_response_size=20
smp_characteristic.max_write_without_response_size=20
Sending request...OK
Received response: header=Header(op=<OP.READ_RSP: 1>, version=<Version.V0: 0>, flags=<Flag: 0>, length=25, group_id=<GroupId.OS_MANAGEMENT: 0>, sequence=0, command_id=<OSManagement.MCUMGR_PARAMETERS: 6>) sequence=0 buf_size=2475 buf_count=4
2024-03-30 18:20:23,372 bleak.backends.winrt.client MainThread DEBUG: Disconnecting from BLE device...
2024-03-30 18:20:26,576 bleak.backends.winrt.client Dummy-2 DEBUG: max_pdu_size_changed_handler: 23
2024-03-30 18:20:26,577 bleak.backends.winrt.client Dummy-3 DEBUG: session_status_changed_event_handler: id: BluetoothLE#BluetoothLEe0:d4:64:58:c4:91-f2:0d:69:5c:11:6f, error: <BluetoothError.SUCCESS: 0>, status: <GattSessionStatus.CLOSED: 0>
2024-03-30 18:20:26,578 bleak.backends.winrt.client MainThread DEBUG: closing requester
2024-03-30 18:20:26,578 bleak.backends.winrt.client MainThread DEBUG: closing session

Should we go back to handling special case on Linux and then assuming that mtu_size (minus 3) is correct on MacOS and Windows:

        # BlueZ doesn't have a proper way to get the MTU, so we have this hack.
        # If this doesn't work for you, you can set the client._mtu_size attribute
        # to override the value instead.
        if self._client._backend.__class__.__name__ == "BleakClientBlueZDBus":
            await self._client._backend._acquire_mtu()