Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MTU size incorrect on Windows #1497

Closed
ddomnik opened this issue Jan 22, 2024 · 4 comments · Fixed by #1552
Closed

MTU size incorrect on Windows #1497

ddomnik opened this issue Jan 22, 2024 · 4 comments · Fixed by #1552
Labels
Backend: WinRT Issues or PRs relating to the WinRT backend bug Something isn't working

Comments

@ddomnik
Copy link

ddomnik commented Jan 22, 2024

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)

trace

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
Copy link
Collaborator

dlech commented Jan 23, 2024

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.

@dlech 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
@ddomnik
Copy link
Author

ddomnik commented Jan 23, 2024

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 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
@dlech
Copy link
Collaborator

dlech commented Jan 23, 2024

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
Copy link
Contributor

JPHutchins commented Mar 31, 2024

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

dlech added a commit that referenced this issue Apr 29, 2024
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 a commit that referenced this issue Apr 29, 2024
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 dlech mentioned this issue May 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backend: WinRT Issues or PRs relating to the WinRT backend bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants