Connecting to a custom device from ubuntu 23.04 fails, but works on Windows 11 and MacOS Ventura

[sigsbeeus]

We have a custom device with several services that we can connect to using python and bleak from a client running on Windows 11 and MacOS Ventura. The same code fails when connecting from Ubunto 23.04. The relevant btmon dump shows this:

> ACL Data RX: Handle 16 flags 0x02 dlen 7                         #23 9.995607
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 512
> HCI Event: LE Meta Event (0x3e) plen 11                         #24 10.035935
      LE Data Length Change (0x07)
        Handle: 16 Address: E0:C0:BF:18:35:C5 (Static)
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> HCI Event: LE Meta Event (0x3e) plen 12                         #25 10.036901
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 16 Address: E0:C0:BF:18:35:C5 (Static)
        Features: 0xff 0x01 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Peripheral-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
          LE 2M PHY
< ACL Data TX: Handle 16 flags 0x00 dlen 7                        #26 10.037131
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 517
< ACL Data TX: Handle 16 flags 0x00 dlen 7                        #27 10.037144
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5            #28 10.079935
        Num handles: 1
        Handle: 16 Address: E0:C0:BF:18:35:C5 (Static)
        Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5            #29 10.080937
        Num handles: 1
        Handle: 16 Address: E0:C0:BF:18:35:C5 (Static)
        Count: 1
> ACL Data RX: Handle 16 flags 0x02 dlen 9                        #30 10.131517
      ATT: Error Response (0x01) len 4
        Exchange MTU Request (0x02)
        Handle: 0x0000
        Error: Invalid PDU (0x04)               <--------------------------------------------- huh?
@ MGMT Command: Disconnect (0x0014) plen 7                   {0x0001} 12.323655
        LE Address: E0:C0:BF:18:35:C5 (Static)
< HCI Command: Disconnect (0x01|0x0006) plen 3                    #31 12.323705

On the bleak client side, client.services is empty after the "with BleakClient( ... ) as self.client: line.

Does anyone have an idea why bluetooth connections work on everything but linux?

Thank you.

[dlech]

BlueZ tends to disconnect when it receives unexpected responses while other OSes tend to be a bit more forgiving. Where you wrote "huh", indeed the device should not be sending this, but rather an MTU exchange response. If you can fix the firmware on the device, then you should be able to make it work with BlueZ.

[sigsbeeus]

I'm not sure I'm buying this answer. Here's an equivalent wireshark capture of the MTU exchange on Windows 11, and there's no error reported:

I also find it hard to believe that bluez is less forgiving than Windows, MacOS, and iOS (which all work). Why in the world would that be the case?

[dlech]

I'm not sure I'm buying this answer. Here's an equivalent wireshark capture of the MTU exchange on Windows 11, and there's no error reported:

I suppose the problem could be with the Bluetooth adapter if it is also different between the OSes you are testing.

I also find it hard to believe that bluez is less forgiving than Windows, MacOS, and iOS (which all work). Why in the world would that be the case?

I have experienced first-hand BlueZ disconnecting because of unexpected responses in multiple cases (e.g. a device that sent a response to write without response request). It is just a design choice of the authors, I guess.

[sigsbeeus]

Well, I take that back. The device being tested supports streaming at a fairly high bitrate, and during firmware development a GATTC_ExchangeMTUCmd() to the connecting device got stuck into the connection sequence on the device. Which, in BLE standard jargon means my device, the "server" side, is apparently a violation of the spec. Removing that fixes up bluez.

Thanks for all who looked at this and responded. Sorry I wasted your time.