Large delay for sending the SRP registration response

[doru91]

I am using this OTBR Docker image together with an NRF52840 dongle. OTBR Docker runs on rpi5 (standard Matter Test Harness configuration).

During Matter commissioning (see attached ss and attached zip file containing the corresponding pcap), the device attaches to the Thread Network and executes 2 SRP registrations:

• reply (packet 19) for the first query ( packet 17) is generated immediately (< 1ms)
• reply (packet 37) for the second query (packet 35) is generated in more than>700ms (this reproduces all the times)

Is this expected? If not do you have some pointers on how to investigate it (for example I don't know exactly how to regenerate the Docker image so some instructions around this would be very helpful)?

air_capture.zip

[jwhui]

Yes, the ~700ms delay for the second SRP registration is expected behavior by design.

Why the first update is immediate (<1ms):

The first SRP update in your capture only registers the host key (862A50F9892ECBF1.default.service.arpa: type KEY) without any services. Under Bonjour/mDNSResponder, individual records registered via DNSServiceRegisterRecord on a shared connection are queued immediately. The registration callback is invoked without waiting for the probing process to finish.

Why the second update takes ~700ms:

The second SRP update registers the actual Matter services (_matterc._udp and _matter._tcp). These services are registered as unique records via DNSServiceRegister, which triggers multicast DNS conflict probing on the local network link per RFC 6762 Section 8.1. Probing involves sending 3 probe packets spaced 250ms apart, resulting in a minimum delay of 750ms before the registration is confirmed and the platform callback is invoked.

The OpenThread Border Router's Advertising Proxy is designed to wait for these registrations (and their probing phase) to complete before committing the update and sending the SRP response back to the Thread client. This ensures that any name conflicts on the infrastructure network are handled before confirming the registration to the client.

This expected delay is also why OpenThread's default SRP server service update timeout (OPENTHREAD_CONFIG_SRP_SERVER_SERVICE_UPDATE_TIMEOUT) is configured to 1250ms (5 * 250ms).