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

[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