Can't query services when not in pairing mode

zilluss · June 24, 2021, 3:06pm

I implemented a fob using an NRF51822 (GitHub - zilluss/Open-Nuki-Fob: Open Source Nuki Fob based on the the NRF51822 SoC). It works without issues on a Nuki V1. I recently bought a Nuki V2 and pairing works without any issues, however if I try to discover the BLE services in the default mode on the V2, the Nuki disconnects without returning any services. In pairing mode querying the services works just fine. What could be the reason?

marc · June 25, 2021, 12:27pm

Hi Martin,

Do you get an error code on the following line?

github.com

zilluss/Open-Nuki-Fob/blob/master/src/main.c#L238

    
      
              if(action_to_execute == ACTION_PAIRING){

                  sd_ble_uuid_vs_add(&NUKI_PAIRING_SERVICE_UUID, &uuid_type);

                  uuid.uuid = 0xe100;

                  uuid.type = uuid_type;

                  err_code = ble_db_discovery_evt_register(&uuid);

              }

              else {

                  sd_ble_uuid_vs_add(&NUKI_KEYTURNER_SERVICE_UUID, &uuid_type);

                  uuid.uuid = 0xe200;

                  uuid.type = uuid_type;

                  err_code = ble_db_discovery_evt_register(&uuid);

              }

          }

          

          static void scan_init(void)

          {

              ret_code_t err_code;

              nrf_ble_scan_init_t init_scan;

          

              memset(&init_scan, 0, sizeof(init_scan));

Also, what uuid_type is used here?
128-Bit or 16-Bit?

best,
Marc

zilluss · June 27, 2021, 11:13pm

Hi Marc, it’s a 128bit UUID, the call to ble_db_discovery_evt_register finishes without an error. What’s odd is that service discovery works while pairing, I get to pair the fob and it shows up on the Nuki’s User list. After pairing no services are ever received from the Nuki. I can see the services from BLE apps on my phone though. Maybe it’s a fundamental issue like the initial MTU being larger in default mode as opposed to pairing mode, because the NRF51822 max MTU is fairly low, I think 23 bytes.

zilluss · June 29, 2021, 6:40pm

The MTU is indeed the issue: The Nuki tries to initiate a MTU exchange but the NRF51822 doesn’t reply, because it’s not implemented. The Nuki then disconnects after a timeout. Will this behaviour be fixed, e.g. with a fallback to the default MTU if the Nuki doesn’t get an MTU reply after a timeout? I have a couple of people asking me why the fob isn’t working with their V2 lock and I’d like to give them an answer.

marc · June 30, 2021, 5:40am

Hi Martin,

The default MTU is always 23 and is only increased if the connecting device responds to the MTU exchange request with an MTU exchange response containing an MTU size larger than 23.

Are you sure there is no MTU reply sent (maybe by the BLE stack itself)?
You may also try to send a MTU reply with 23.

best,
Marc

zilluss · June 30, 2021, 8:22pm

Yes, the BLE stack does not implement MTU exchange at all, so the device doesn’t reply automatically and the API has no functions to do so manually (See for example this reply from Nordic in their forum: https://devzone.nordicsemi.com/f/nordic-q-a/41658/nrf51824-is-support-mtu-change/162312#162312)

Unfortunately, I don’t have a BLE sniffer to provide a trace of the communication. But it’s the most likely explanation why pairing works but unlocking doesn’t, since the Nuki doesn’t do MTU exchange in pairing mode. Since the BLE stack doesn’t automatically reply to the MTU request, and the API doesn’t implement it, there’s no way for me to solve this issue on my side. If you won’t change this behaviour that’s understandable, but I think it would be helpful to note it in the documentation, since I spent quite some time figuring out what the issue was.

zilluss · July 12, 2021, 7:51am

If there’s an update on the issue, even if it’s a “we can’t help you with that” I would appreciate it. I’ve since checked the NRF52832 port of my code (which does support MTU exchange) and got it to pair and unlock my V2 Nuki.