ot-br-posix
ot-br-posix copied to clipboard
Multicast routing after restarting the OTBR
We have an OTBR setup, where multicast routing works (testing with Matter). What we've observed is that after restarting the OTBR, the messages are not delivered to the nodes until the nodes send MLR requests. This probably makes sense since the routing cache is empty after the restart. Is there a way to deal with such a scenario? Does the OTBR support Multicast Listener Discovery?
Here are the logs when the MLR is received (afterwards routing works fine):
Jul 15 10:30:45 qivicon user.info otbr-agent[94]: 01:00:20.882 [I] Platform------: MulticastRoutingManager: UnblockInboundMulticastForwardingCache: Backbone fd11:bf7d:d994:7963:a3:2aff:fe9c:3fe3 => ff35:40:fd00:0:0:0:100:3e8 Thread: OK
Jul 15 10:30:45 qivicon user.info otbr-agent[94]: 01:00:20.882 [I] Platform------: MulticastRoutingManager: UpdateMldReport: address ff35:40:fd00:0:0:0:100:3e8 Added: OK
Jul 15 10:30:45 qivicon user.info otbr-agent[94]: 01:00:20.882 [I] Platform------: MulticastRoutingManager: Add: ff35:40:fd00:0:0:0:100:3e8: OK
Jul 15 10:30:45 qivicon user.info otbr-agent[94]: 01:00:20.882 [I] BbrManager----: Sent MLR.rsp (status=0): OK
Jul 15 10:30:45 qivicon user.info otbr-agent[94]: 01:00:20.884 [I] BbrManager----: Sent BMLR.ntf: OK
@dtodor , thanks for raising this issue.
Does https://github.com/openthread/openthread/pull/7996 help address your issue?
I doubt if there is an issue that needs to be fixed by https://github.com/openthread/openthread/pull/7996.
What is the re-registration delay in BBR dataset. This could be caused by improper reregistration delay, which is 1200 by default (too large for typical home IMO).
Resolved by https://github.com/openthread/openthread/pull/7996