Matter : SRP update error: domain name or RRset is duplicated when using generated factory data.

[abollaert]

Hi,

I've been working on generating my own factory data (using the matter weather station application as an example). I'm using the generate_nrfconnect_chip_factory_data.py script to generate the factory data JSON, and then convert it to a hex file using generate_nrfconnect_chip_factory_data.py.

I also replaced the example device info provider with an internal flash based FactoryDataProvider, and all seems to work properly (I can see the device logging the data that was generated (serial number, discriminator and more)).

However, since using my own factory data, I'm having problems commissioning the device using HomeKit or Google Home (both worked before with the example info provider).

The error I'm getting is [DL]SRP update error: domain name or RRset is duplicated. A quick google doesn't seem to reveal anything however.

I: 76165 [ZCL]Commissioning window is now open
D: 76170 [DMG]Command handler moving to [ Preparing]
D: 76174 [DMG]Command handler moving to [AddingComm]
D: 76179 [DMG]Command handler moving to [AddedComma]
D: 76184 [DMG]Decreasing reference count for CommandHandler, remaining 0
I: 76191 [EM]<<< [E:20170r M:230458302 (Ack:222677858)] (S) Msg TX to 1:06C83329FB703318 [1F5D] --- Type 0001:09 (IM:InvokeCommandResponse)
I: 76203 [IN](S) Sending msg 230458302 on secure session with LSID: 19546
D: 76211 [DMG]Command handler moving to [CommandSen]
D: 76216 [DMG]Command handler moving to [AwaitingDe]
I: 76266 [EM]>>> [E:20170r M:222677859 (Ack:230458302)] (S) Msg RX from 1:06C83329FB703318 [1F5D] --- Type 0000:10 (SecureChannel:StandaloneAck)
D: 76477 [EM]Found matching exchange: 20170r, Delegate: (nil)
D: 76483 [EM]Rxd Ack; Removing MessageCounter:230458302 from Retrans Table on exchange 20170r
E: 76581 [DL]SRP update error: domain name or RRset is duplicated
E: 78565 [DL]SRP update error: domain name or RRset is duplicated
E: 81827 [DL]SRP update error: domain name or RRset is duplicated
E: 87231 [DL]SRP update error: domain name or RRset is duplicated
E: 96270 [DL]SRP update error: domain name or RRset is duplicated
E: 111494 [DL]SRP update error: domain name or RRset is duplicated
E: 137226 [DL]SRP update error: domain name or RRset is duplicated
E: 180823 [DL]SRP update error: domain name or RRset is duplicated
E: 254806 [DL]SRP update error: domain name or RRset is duplicatedI: 76165 [ZCL]Commissioning window is now open
D: 76170 [DMG]Command handler moving to [ Preparing]
D: 76174 [DMG]Command handler moving to [AddingComm]
D: 76179 [DMG]Command handler moving to [AddedComma]
D: 76184 [DMG]Decreasing reference count for CommandHandler, remaining 0
I: 76191 [EM]<<< [E:20170r M:230458302 (Ack:222677858)] (S) Msg TX to 1:06C83329FB703318 [1F5D] --- Type 0001:09 (IM:InvokeCommandResponse)
I: 76203 [IN](S) Sending msg 230458302 on secure session with LSID: 19546
D: 76211 [DMG]Command handler moving to [CommandSen]
D: 76216 [DMG]Command handler moving to [AwaitingDe]
I: 76266 [EM]>>> [E:20170r M:222677859 (Ack:230458302)] (S) Msg RX from 1:06C83329FB703318 [1F5D] --- Type 0000:10 (SecureChannel:StandaloneAck)
D: 76477 [EM]Found matching exchange: 20170r, Delegate: (nil)
D: 76483 [EM]Rxd Ack; Removing MessageCounter:230458302 from Retrans Table on exchange 20170r
E: 76581 [DL]SRP update error: domain name or RRset is duplicated
E: 78565 [DL]SRP update error: domain name or RRset is duplicated
E: 81827 [DL]SRP update error: domain name or RRset is duplicated
E: 87231 [DL]SRP update error: domain name or RRset is duplicated
E: 96270 [DL]SRP update error: domain name or RRset is duplicated
E: 111494 [DL]SRP update error: domain name or RRset is duplicated
E: 137226 [DL]SRP update error: domain name or RRset is duplicated
E: 180823 [DL]SRP update error: domain name or RRset is duplicated
E: 254806 [DL]SRP update error: domain name or RRset is duplicated

For reference: the factory data I generated:

{
  "version": 1,
  "sn": "177449",
  "vendor_id": 65521,
  "product_id": 32784,
  "vendor_name": "Vendor",
  "product_name": "Product",
  "date": "2022-12-15",
  "hw_ver": 0,
  "hw_ver_str": "r0",
  "rd_uid": "hex:caa92daded1e2067b278f9f04c8ddc3c",
  "dac_cert": "hex:308201e73082018ea0030201020208467f5762c8dc90d5300a06082a8648ce3d040302303d3125302306035504030c1c4d6174746572204465762050414920307846464631206e6f2050494431143012060a2b0601040182a27c02010c04464646313020170d3232303333313030303030305a180f39393939313233313233353935395a30533125302306035504030c1c4d61747465722044657620444143203078464646312f30783830313031143012060a2b0601040182a27c02010c044646463131143012060a2b0601040182a27c02020c04383031303059301306072a8648ce3d020106082a8648ce3d0301070342000439ef6c9d9c997ba2c7319a4c73c9bf47dbcdbc42c5413eec145275b88fc11ab1ad0bc33ef14c279404429f2f5ee70a051b72e6c7b9e7354edaf92ab4fff8842fa360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e0416041432fc27d1ef5343a2f364f02cf470cb674780e5aa301f0603551d2304183016801463540e47f64b1c38d13884a462d16c195d8ffb3c300a06082a8648ce3d040302034700304402206f11b2050bd3d2e36c246130086c2201b08cf99d5a77b23a900500fbef0913b20220136ab6a0bb8bd4f4adf80a1234cfefb67f0afb7355f1dca472da16ac4a3664e5",
  "dac_key": "hex:dafb2c7288a4708669230d9fdba8953f103ba85ad5cf94aa713de0a23eb4bede",
  "pai_cert": "hex:308201cb30820171a003020102020856ad8222ad945b64300a06082a8648ce3d04030230303118301606035504030c0f4d617474657220546573742050414131143012060a2b0601040182a27c02010c04464646313020170d3232303230353030303030305a180f39393939313233313233353935395a303d3125302306035504030c1c4d6174746572204465762050414920307846464631206e6f2050494431143012060a2b0601040182a27c02010c04464646313059301306072a8648ce3d020106082a8648ce3d03010703420004419a9315c2173e0c8c876d03ccfc944852647f7fec5e5082f4059928eca894c594151309ac631e4cb03392af684b0bafb7e65b3b8162c2f52bf931b8e77aaa82a366306430120603551d130101ff040830060101ff020100300e0603551d0f0101ff040403020106301d0603551d0e0416041463540e47f64b1c38d13884a462d16c195d8ffb3c301f0603551d230418301680146afd22771f511fecbf1641976710dcdc31a1717e300a06082a8648ce3d0403020348003045022100b2ef27f49ae9b50fb91eeac94c4d0bdbb8d7929c6cb88face529368d12054c0c0220655dc92b86bd909882a6c62177b825d7d05edbe7c22f9fea71220e7ea703f891",
  "passcode": 83665196,
  "spake2_it": 10000,
  "spake2_salt": "hex:1e134ebb0470a1b0bb8233a078d9aaaca50f81f62bac2cb6",
  "spake2_verifier": "hex:dc401e304bc78b1c443c5cff6b832c1ae542cdd85a4b87a290c450d8293fe6150444dbb0ffbbfa05b7fc6e487e92bd9d2be76e5668872dc9a09ec1fbc124dbbfe6374e6ae2b162cd4bc2d160886c46ce1653b828aa1173ef5c58fce6f5f348ed49",
  "discriminator": 2677,
  "enable_key": "hex:168963dbc92ceff652c58e56fced20e0"
}

I suppose there must be something I'm missing here, but I thought the SRP name was generated based on the EUI64, which is unique per device?

Can anyone share some pointers as to what is causing this error?

Thanks and kind regards,

-Alex

[AHaug]

Hi,

I'm not sure what might cause the issue, but I had some luck finding some issues that might be related to what you're observing. Let me know if you've seen them before or if they give you any clues at all.

I'm assuming you've followed https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/matter/nrfconnect_factory_data_configuration.html w.r.t. configuring the factory data? If not, please cross-examine this documentation to see if you've missed anything

• https://github.com/project-chip/connectedhomeip/issues/20803
  •  "Currently, the SRP Replication feature is not supported on the current Thread 1.3, hence the border routers from two separate Thread Networks can discover its services within a local network (using backbone interface) but synchronization and replication handling are not implemented."

This issue also links to https://github.com/project-chip/connectedhomeip/issues/21101 at the bottom.

• https://github.com/openthread/openthread/issues/7644
  • My guess/theory is that perhaps the matter code base somehow not set/update the new address on SRP client and SRP client is therefore registering the previous host name and address that was set on it (when it discovers the SRP server again).

Let me know if any of these items are of help at all, and please feel free to come with related follow up questions. I'll query the Matter developers if your question is still unanswered.

Kind regards,
Andreas 

[abollaert]

Hi Andreas,

thanks for the reply. I've been digging around some more, playing with different border routers (HomeKit, OTBR, and a Nest Hub) but the behaviour is the same across all of them.

When looking at the logs of OTBR, I can see this passing by:

Dec 19 11:00:23 otbr-agent[568]: 00:13:28.658 [W] SrpServer-----: Name conflict: host name 8EDC2E7DD21F3B00.default.service.arpa. has already been allocated
Dec 19 11:00:23 otbr-agent[568]: 00:13:28.658 [W] SrpServer-----: Failed to process DNS Update section: Duplicated
Dec 19 11:00:23 otbr-agent[568]: 00:13:28.658 [W] SrpServer-----: Send fail response: 6

Happens every time when I reboot my device.

Googling does not seem to yield many results, except for this one:

https://github.com/openthread/openthread/issues/8056

Where it is said that SRP updates are signed using ECDSA, and the corresponding key is stored in NVM somewhere, so it would then seem that key gets lost across reboots for some reason? 

Do you now where to start looking for this?

Kind regards and thanks,

-Alex

[abollaert]

It would look like the problem was being caused by me moving the settings_storage to the external flash.

When enabling the factory_data I tried using the example layout (factory_data at 0xfb000, size 0x1000), but that didn't work because fprotect fails using the sample layout (apparently it can't handle a size of 0x1000 because CONFIG_FPROTECT_BLOCK_SIZE is defined as 0x4000 for nRF5340_cpuapp, which would mean I'd have to decrease the size of the settings_storage, which then caused other problems).

So I moved the settings_storage to external flash, increased the size of the factory_data to something fprotect likes (0x4000), and everything seemed to work except for the SRP errors.

Moving the settings back to internal flash makes the SRP errors go away, but then I'm back where I started. I could move factory data to external flash, but then I don't have fprotect, and I'm not sure if I can still use nfrjprog to flash the hex file.

Is there a way to have the factory data and the settings on the internal flash for the nrf53 (all examples use this layout but I think it can't work given the constraints imposed by fprotect). Unless I'm mistaken?

Kind regards and thanks,

-Alex 

[AHaug]

Hi,

I've brought this up with the Matter team and they have some input on the SRP issue and they need some time to investigate and do some tests internally to see if they determine if there is an issue with fprotect with the configuration you're describing.

Regarding the "E: 76581 [DL]SRP update error: domain name or RRset is duplicated"-error: This isn't related to Factory Data. That error means that OTBR already has the same SRP entry as requested by the device. They suspect that it might be caused due to a non-cleared SRP table on the OTBR. Could you try to clear the SRP table, perform a factory reset of the device (nRF device) and try to comission the device again?

I'll let you know as soon as I hear back from them, however that might not be before new years. I'll be out of office until the 29th (Dec) after today, so if there comes more info related to this issue from the Matter team in the meanwhile I won't be able to communicate that before earliest that date.

Kind regards,
Andreas

[AHaug]

Hi,

Did you have any success with the method I suggested?

Kind regards,
Andreas

[abollaert]

Hi Andreas,

sorry for the late reply, I was on vacation.

I just solved the issue by moving everything on the internal flash for now (which meant I had to decrease the allotted size for the primary_app though which is something I was trying to avoid). But once I did that the issue went away.

I also tried moving the factory data onto the external flash but that doesn't seem to be supported.

Kind regards,

Alex

[abollaert]

Hi Andreas,

went back to this issue again, and figured out how to resolve it properly by looking at the matter weather station example.

Apparently you can override the FPROTECT_BLOCK_SIZE in the Kconfig like so:

# Overwrite the Fprotect block size to fit the size of the factory data partition.
# See lib/fprotect/Kconfig to get full description of this config.
config FPROTECT_BLOCK_SIZE
	hex
	default 0x1000

I must have missed this before (going with the defaults).

Kind regards,

-Alex

[AHaug]

Hi,

Glad to hear you found a solution. 

Let me know if we can close this case and verify the solution and/or if you have any additional questions to the topic in this case

Kind regards,
Andreas

[abollaert]

Hi Andreas,

sure the ticket can be closed.

Thanks,

-Alex