Hi
Smart lock firmware seems to have an issue when answering the Request Authorization Entries (0x0009) command with count = 1 and offset > 0 when multiple authorizations exist in the smart lock. In this case I we’ve seen the firmware sometimes answer with a wrong authorization entry (for example repeating an entry retrieved for the last offset requested) and sometimes it doesn’t answer at all leaving the client to time out waiting for an answer. This apparently depending on the number of authorizations and the past order of additions or deletions of authorizations. I’ve seen the issue at least in firmware v4.9.6 and v5.7.11.
BLE communication showing the simplest case of the issue with 2 authorizations in the smart lock. Shown are decrypted portions of the packets (PDATA). This example is using Smart Lock Go with firmware v5.7.11. It can be reproduced by factory resetting the smart lock and adding one additional authorization after the authorization made by the mobile app on initialization.
CL = client
SL = Nuki smart lock
SL answers correctly for offset=0 count=1:
CL: 0x0001 request data, challenge
df ef 02 00 01 00 04 00
23 7d
SL: 0x0004 challenge
df ef 02 00 04 00 eb aa
33 18 f1 28 35 56 2a ee
c9 c1 e4 b5 92 34 b9 26
4b ee d7 09 81 06 52 13
c0 c7 9a e5 61 77 aa 10
CL: 0x0009 request authorization entries, offset=0, count=1
df ef 02 00 09 00 00 00
01 00 eb aa 33 18 f1 28
35 56 2a ee c9 c1 e4 b5
92 34 b9 26 4b ee d7 09
81 06 52 13 c0 c7 9a e5
61 77 40 e2 01 00 b5 de
SL: 0x0027 authorization entry count, count=2
df ef 02 00 27 00 02 00
52 c7
SL: 0x000a authorization entry, type=app, name=Testapp, ...
df ef 02 00 0a 00 df ef
02 00 00 54 65 73 74 61
70 70 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 01 01 ea 07 06
1e 08 0e 32 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 95 23 84 4b 00 5a 80
SL timeouts for offset=1 count=1:
CL: 0x0001 request data, challenge
df ef 02 00 01 00 04 00
23 7d
SL: 0x0004 challenge
df ef 02 00 04 00 3d b7
82 53 24 e6 6b b5 53 f9
28 81 05 55 16 38 e5 cb
60 02 be 98 1d 53 98 96
d9 68 30 29 65 4c c7 fc
CL: 0x0009 request authorization entries, offset=1, count=1
df ef 02 00 09 00 01 00
01 00 3d b7 82 53 24 e6
6b b5 53 f9 28 81 05 55
16 38 e5 cb 60 02 be 98
1d 53 98 96 d9 68 30 29
65 4c 40 e2 01 00 f3 22
CL times out after waiting 10s for any reply from SL
SL answers correctly with offset=0, count=2:
CL: 0x0001 request data, challenge
df ef 02 00 01 00 04 00
23 7d
SL: 0x0004 challenge
df ef 02 00 04 00 1b ec
39 b4 d2 40 be 55 d3 fe
ab 5d 24 ec bf c4 f1 90
af f8 cd 8f b3 9c 7b 18
a9 86 49 27 c5 97 58 0a
CL: 0x0009 request authorization entries, offset=0, count=2
df ef 02 00 09 00 00 00
02 00 1b ec 39 b4 d2 40
be 55 d3 fe ab 5d 24 ec
bf c4 f1 90 af f8 cd 8f
b3 9c 7b 18 a9 86 49 27
c5 97 40 e2 01 00 07 1d
SL: 0x0027 authorization entry count, count=2
df ef 02 00 27 00 02 00
52 c7
SL: 0x000a authorization entry, type=app, name=Testapp, ...
df ef 02 00 0a 00 df ef
02 00 00 54 65 73 74 61
70 70 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 01 01 ea 07 06
1e 08 0e 32 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 95 23 84 4b 00 5a 80
SL: 0x000a authorization entry, type=app, name=John Doe, ...
df ef 02 00 0a 00 81 51
00 00 00 4a 6f 68 6e 20
44 6f 65 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 01 01 e9 07 03
01 00 02 3a ea 07 06 18
0e 08 0f 01 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 1c ad e0 5a 00 17 4e