The SRP server information loss without otbr-agent restart and otbr-agent communication with mdns fail.

[jinpeng1989]

There is no SRP information(lease time=86400 second) in SRP server and can not browse in mdnsd by dns-sd. Please help to check.

1. ot-br-posix commit id: 3a98779
2. IEEE 802.15.4 hardware platform: SL-OPENTHREAD/2.1.0.0_GitHub-8f92d2dc8_v2; EFR32
3. One otbr and 32 SED

syslog_srp_lost.log

[abtink]

I see in the logs that otbr is detached and disabled a bunch of time (which then correctly stops SRP server and removes any previous registerations).

Suggest investigating further why this may be happening in your setup.

abtink ~/Downloads $ cat syslog_srp_lost.log | grep otbr | grep Role
Thu Sep 29 10:10:40 2022 user.notice otbr-agent[2904]: 00:22:34.146 [N] Mle-----------: Role disabled -> detached
Thu Sep 29 10:10:41 2022 user.notice otbr-agent[2904]: 00:22:35.366 [N] Mle-----------: Role detached -> child
Thu Sep 29 10:12:40 2022 user.notice otbr-agent[2904]: 00:24:34.254 [N] Mle-----------: Role child -> router
Thu Sep 29 10:32:10 2022 user.notice otbr-agent[2904]: 00:44:03.976 [N] Mle-----------: Role router -> leader
Thu Sep 29 11:15:09 2022 user.notice otbr-agent[2904]: 01:27:03.534 [N] Mle-----------: Role leader -> detached
Thu Sep 29 11:15:09 2022 user.notice otbr-agent[2904]: 01:27:03.534 [N] Mle-----------: Role detached -> disabled
Thu Sep 29 11:15:26 2022 user.notice otbr-agent[2904]: 01:27:20.540 [N] Mle-----------: Role disabled -> detached
Thu Sep 29 11:15:30 2022 user.notice otbr-agent[2904]: 01:27:24.461 [N] Mle-----------: Role detached -> leader
Thu Sep 29 12:54:20 2022 user.notice otbr-agent[2904]: 03:06:14.576 [N] Mle-----------: Role leader -> detached
Thu Sep 29 12:54:20 2022 user.notice otbr-agent[2904]: 03:06:14.578 [N] Mle-----------: Role detached -> disabled
Thu Sep 29 12:54:20 2022 user.notice otbr-agent[2904]: 03:06:14.583 [N] Mle-----------: Role disabled -> detached
Thu Sep 29 12:54:25 2022 user.notice otbr-agent[2904]: 03:06:19.027 [N] Mle-----------: Role detached -> leader

[jinpeng1989]

After the thread stop then start, all the previous registerations are removed and the SRP server port do not change. How does the client sense the loss of information and re-register.

[jinpeng1989]

My test sequence:

root@KNBA5F00000C:~# ot-ctl netdata show
Prefixes:
fd11:22:0:0::/64 paros med e800
Routes:
Services:
44970 5d fd0aa7552cf5dd90ab8ac88923f6c856d11f s e800
Done
root@KNBA5F00000C:~# ot-ctl child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|D|N|Ver|CSL|QMsgCnt| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+---+---+-------+------------------+
|   1 | 0xe801 |       1800 |         28 |     3 |  143 |0|0|1|  2| 0 |     1 | 7ea63512744eafa0 |

Done
root@KNBA5F00000C:~# ot-ctl srp server service
56FD10F18ADB._knx._udp.default.service.arpa.
    deleted: false
    subtypes: _56FD10F18ADB
    port: 5683
    priority: 0
    weight: 0
    ttl: 3600
    TXT: [dt=515041323839322f5749, sw=302e302e3536, eui=39663662363730313035653138303030, rl=307865383031, pm=30]
    host: 56FD10F18ADB.knx.default.service.arpa.
    addresses: [fd11:22:0:0:d467:6d9a:9296:cbc7]
Done
root@KNBA5F00000C:~# ot-ctl thread stop
Done
root@KNBA5F00000C:~# ot-ctl child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|D|N|Ver|CSL|QMsgCnt| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+---+---+-------+------------------+
|   1 | 0xe801 |       1800 |         59 |     3 |  143 |0|0|1|  2| 0 |     1 | 7ea63512744eafa0 |

Done
root@KNBA5F00000C:~# ot-ctl srp server service
56FD10F18ADB._knx._udp.default.service.arpa.
    deleted: false
    subtypes: _56FD10F18ADB
    port: 5683
    priority: 0
    weight: 0
    ttl: 3600
    TXT: [dt=515041323839322f5749, sw=302e302e3536, eui=39663662363730313035653138303030, rl=307865383031, pm=30]
    host: 56FD10F18ADB.knx.default.service.arpa.
    addresses: [fd11:22:0:0:d467:6d9a:9296:cbc7]
Done
root@KNBA5F00000C:~# ot-ctl thread start
Done
root@KNBA5F00000C:~# ot-ctl netdata show
Prefixes:
fd11:22:0:0::/64 paros med e800
Routes:
Services:
44970 5d fd0aa7552cf5dd90ab8ac88923f6c856d11f s e800
Done
root@KNBA5F00000C:~# ot-ctl child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|D|N|Ver|CSL|QMsgCnt| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+---+---+-------+------------------+
|   1 | 0xe801 |       1800 |        107 |     3 |  143 |0|0|1|  2| 0 |     2 | 7ea63512744eafa0 |

Done
root@KNBA5F00000C:~# ot-ctl srp server service
Done

[abtink]

What is the reason for stopping Thread and starting again?
thread stop will disable thread operation on device.

Suggest if you need to stop and then (re) start Thread, to also disable and (re)enable SRP server. This will then ensure that SRP server starts with a new port.

[jinpeng1989]

The aim is to stop a OTBR functioning in the thread network without power off. This OTBR may be re-enabled later.

[abtink]

Then as I suggested, it make sense to also explicitly disable SRP server (e.g. srp server disable cli cmd) at the same time you disable Thread (thread stop) and (re) enable it along with Thread operation later.

Alternately, you can consider using the"auto-enable" feature (added in #8129) if you are operating the device as 1.3 BR.

[superwhd]

Speaking of the mDNS issue, I found there are a lot of warning/error logs for mdnsd. Could you check if it's running normally? Has it been granted sufficient permissions?

Thu Sep 29 09:47:47 2022 daemon.err mdnsd[1747]: Default: mDNSResponder (Engineering Build) (Feb 15 2021 15:22:37) starting
Thu Sep 29 09:47:47 2022 daemon.err mdnsd[1747]: Default: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
Thu Sep 29 09:47:47 2022 daemon.err mdnsd[1747]: Default: mDNSPlatformSourceAddrForDest: connect 1.1.1.1 failed errno 101 (Network unreachable)
Thu Sep 29 09:47:47 2022 daemon.notice mDNSResponderPosix: Default: mDNSPlatformSendUDP got error 1 (Operation not permitted) sending packet to 224.0.0.251 on interface 192.168.1.5/eth0/3
Thu Sep 29 09:47:47 2022 daemon.notice mDNSResponderPosix: Default: mDNSPlatformSendUDP got error 99 (Address not available) sending packet to ff02::fb on interface 192.168.1.5/eth0/3
Thu Sep 29 09:47:47 2022 daemon.notice mDNSResponderPosix: Default: mDNSPlatformSendUDP got error 1 (Operation not permitted) sending packet to 224.0.0.251 on interface 192.168.8.1/br-lan/6
Thu Sep 29 09:47:47 2022 daemon.notice mDNSResponderPosix: Default: mDNSPlatformSendUDP got error 99 (Address not available) sending packet to ff02::fb on interface 192.168.8.1/br-lan/6
Thu Sep 29 09:47:47 2022 daemon.notice mDNSResponderPosix: Default: mDNSPlatformSendUDP got error 99 (Address not available) sending packet to ff02::fb on interface 192.168.1.5/eth0/3

[jinpeng1989]

The mdnsd is granted root permission.