search

project-chip / connectedhomeip

Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
https://buildwithmatter.com
Apache License 2.0
7.33k stars 1.97k forks source link

[BUG] BLE Commissioning via Apple Home fails with Linux examples #32895

Closed bufl-blum closed 4 months ago

bufl-blum commented 5 months ago

Reproduction steps

We are developing a Matter device on the Linux platform and we are not able to commission our Matter device over BLE Commissioning with the Apple Home app. The BLE connection always gets closed at commissioning step 11 or 12 with the error BtpEngine unsub failed (iOS logs). The Matter device reports "no endpoint for BLE sent data ack", because BLE connection was closed.

Steps to reproduce the error:

  1. Prepare Raspberry Pi like in the tutorial
  2. Cross compile all-cluster example for arm64 "./scripts/build/build_examples.py --target linux-arm64-all-clusters-clang build"
  3. start application on raspi "./chip-all-cluster-app --wifi" (important no interface eth0 or wlan0 are connected)
  4. open the Apple Home App on an iPhone with in my case iOS 17.4, add device and scan QR-Code
  5. BLE Commissioning process starts ...

Logs BLE commissioning over AppleHome fails (chip-all-clusters-app): dut_ble-commissioning_via_AppleHome.txt applehome_fails.txt

Logs BLE commissioning over AppleHome fails (custom-app based on Matter SDK Tag 1.2.0.1): dut_custom_app.txt applehome_fails_customapp.txt

Bug prevalence

Whenever I do this

GitHub hash of the SDK that was being used

5bb5c9e23d532cea40476fc0bd1d3008522792ba

Platform

darwin, raspi, other

Platform Version(s)

testet with: v1.3-branch, 1.2.0.1

Anything else?

When I do the BLE commission on iOS with the Samsung Smarthings App or Tuya App everything is doing well. With Apple Home or Google Home I always get this error. The error appears with my custom Matter device implementation on the Linux platform, but also at the all-cluster-app and lighting-app examples (Linux platform) from project-chip repo. When I use the chip-tool paring ble-wifi command commissioning is successful. Network Commissioning (if I manually add raspi on network) works with every app on iOS.

Logs successful BLE commissioning with iOS SmartThings App (chip-all-clusters-app): dut_ble-commissioning_via_smartthings.txt smartthings_success.txt

Logs successful BLE commissioning with chiptool (chip-all-clusters-app): dut_ble-commissioning_via_chiptool.txt chip-tool.txt

bzbarsky-apple commented 5 months ago

@bufl-blum Please file a feedback assistant ticket following the instructions below and post the ticket ID here. I'll follow up on it. The ticket will have a lot more in the way of logs on the Home side...

Feedback assistant ticket:

bufl-blum commented 5 months ago

Hello @bzbarsky-apple, I have already opened a ticket with Apple feedback assistant FB13685680. @woody-apple wrote to me there to open a GitHub issue.

bzbarsky-apple commented 5 months ago

@bufl-blum Thank you for that reference; that's very helpful.

Looking at the logs there, what it looks like from our end is that we send the attestation request command and then the Bluetooth connection drops. The Matter logs say that, obviously, but so do the bluetoothd logs, where it's pretty clear that the device named "ubuntu" disconnects from us (where "us" is the iPhone doing the commissioning in this case).

What's not clear to me is why that would happen with a recent-ish SDK on the Raspberry Pi, which is a configuration that gets tested all the time.... It's worth double-checking that the server in this case is using GATT Indications, not Notifications, because for a while there was some confusion about that on some platforms (but I thought not Linux?) that could lead to these sorts of symptoms. But past that, it would be good to find out what the Bluetooth stack on the "ubuntu" device thinks is going on when this happens.

bufl-blum commented 5 months ago

I checked the BLE stack log output with btmon and found the configuration issue.

> ACL Data RX: Handle 64 flags 0x02 dlen 118                                                                                                                                          #219 [hci0] 44.751201
      ATT: Write Request (0x12) len 113
        Handle: 0x0017
          Data: 0d110e6a0000f665001a6bd20c3be75ded0d7c899b96623fc6d8f028ae7cb5cf0d6d33aeb9536a69f4944fe8cd590f51b4e29858659ca96a7dd55ee864d03196cda444c69f016fe474914a73373799497fe95b74d1731aabcbcbaa099a9>
> ACL Data RX: Handle 64 flags 0x02 dlen 9                                                                                                                                            #220 [hci0] 44.751271
      ATT: Error Response (0x01) len 4
        Read Request (0x0a)
        Handle: 0x001b
        Error: Insufficient Authentication (0x05)
< ACL Data TX: Handle 64 flags 0x00 dlen 6                                                                                                                                            #221 [hci0] 44.753560
      SMP: Security Request (0x0b) len 1
        Authentication requirement: Bonding, No MITM, SC, No Keypresses, CT2 (0x29)
> ACL Data RX: Handle 64 flags 0x02 dlen 6                                                                                                                                            #222 [hci0] 44.809927
      SMP: Pairing Failed (0x05) len 1
        Reason: Unspecified reason (0x08)
@ MGMT Event: Authentication Failed (0x0011) plen 8                                                                                                                               {0x0001} [hci0] 44.810004
        LE Address: 4F:42:4D:FC:37:38 (Resolvable)
        Status: Authentication Failed (0x05)
< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                                                                                        #223 [hci0] 44.810073
        Handle: 64
        Reason: Authentication Failure (0x05)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                                                                                #224 [hci0] 44.810205
        Num handles: 1
        Handle: 64
        Count: 2
> HCI Event: Command Status (0x0f) plen 4                                                                                                                                             #225 [hci0] 44.810484
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                                        #226 [hci0] 44.870747
        Status: Success (0x00)
        Handle: 64
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                 {0x0001} [hci0] 44.870815
        LE Address: 4F:42:4D:FC:37:38 (Resolvable)
        Reason: Connection terminated by local host (0x02)

The iPhone advertises a BatteryService via BLE, which requires pairing if accessed. Bluez includes a battery plugin by default which tries to connect to the battery service. The authentication fails, because in this case no BLE pairing bonding has been done.

So disabling the battery plugin on raspi needs to be done and everything works.

Prevent the bluetooth.service on raspi to start the battery plugin can be done via -P flag:

  1. Edit the bluetooth.service unit by running the following command:

    sudo systemctl edit bluetooth.service

  2. Add the following content to the override file:

    [Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/bluetoothd -E -P battery

I think it would be helpful for other people to add a few lines here to save them from making the same configuration mistake, wouldn't it?

bzbarsky-apple commented 5 months ago

@bufl-blum Yes, that documenation update would make a lot of sense. Are you able to create a pull request with your proposed documentation changes? I'm not 100% sure I am following what needs to be added to the override file in this case; want to make sure what goes in the docs is right.

And thank you for figuring out what's going on here!