MTU size incorrect on Windows #1497

ddomnik · 2024-01-22T20:07:46Z

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.

The text was updated successfully, but these errors were encountered:

dlech · 2024-01-23T00:05:15Z

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 · 2024-01-23T17:49:15Z

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 · 2024-01-23T18:48:43Z

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 · 2024-03-31T01:22:50Z

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()

Users have reported that the max pdu size was wrong on some devices. This was happening because the max_pdu_size_changed event was happeing after the get_services() call returned. This adds an event to wait for the max_pdu_size_changed event to happen and updates the characteristics in the service dictionary after the fact to ensure they have the correct value. The service_explorer example is also updated to show the value to help with future troubleshooting. Fixes: #1497

dlech added 3rd party issue The issue is with the Bluetooth stack, the BLE device, or other 3rd party code not with Bleak itself Backend: WinRT Issues or PRs relating to the WinRT backend labels Jan 23, 2024

dlech added bug Something isn't working and removed 3rd party issue The issue is with the Bluetooth stack, the BLE device, or other 3rd party code not with Bleak itself labels Jan 23, 2024

JPHutchins mentioned this issue Mar 31, 2024

Bug fixing for zephyr intercreate/smpclient#4

Closed

7 tasks

dlech mentioned this issue Apr 29, 2024

backends/winrt: fix max pdu update race #1552

Merged

dlech closed this as completed in #1552 Apr 29, 2024

dlech mentioned this issue May 4, 2024

Release/0.22.0 #1562

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MTU size incorrect on Windows #1497

MTU size incorrect on Windows #1497

ddomnik commented Jan 22, 2024 •

edited

Loading

dlech commented Jan 23, 2024

ddomnik commented Jan 23, 2024 •

edited

Loading

dlech commented Jan 23, 2024 •

edited

Loading

JPHutchins commented Mar 31, 2024 •

edited

Loading

MTU size incorrect on Windows #1497

MTU size incorrect on Windows #1497

Comments

ddomnik commented Jan 22, 2024 • edited Loading

Description

dlech commented Jan 23, 2024

ddomnik commented Jan 23, 2024 • edited Loading

dlech commented Jan 23, 2024 • edited Loading

JPHutchins commented Mar 31, 2024 • edited Loading

ddomnik commented Jan 22, 2024 •

edited

Loading

ddomnik commented Jan 23, 2024 •

edited

Loading

dlech commented Jan 23, 2024 •

edited

Loading

JPHutchins commented Mar 31, 2024 •

edited

Loading