Address queries are forwarded by the node even though it is the one which resolves the address

[sarveshkumarv3]

Describe the bug A clear and concise description of what the bug is.

Observing that the address query is being forwarded by the router device even though it is the final node that resolves the address and sends the Address notify. This leads to too many address queries eventually running out of buffers.

There could have been similar discussions in the past (ex. #8441)

To Reproduce Information to reproduce the behavior, including:

1. Git commit id
2. IEEE 802.15.4 hardware platform
3. Build steps
4. Network topology

Expected behavior A clear and concise description of what you expected to happen.

The testing was performed with 2 devices in router mode, the Eid-cache on router-2 was cleared and a ping packet was sent to Router-1 which forces 1 address query to be sent from Router-2 to Router-1

Console/log output If applicable, add console/log output to help explain your problem.

Added some extra prints to debug this issue

It is observed that Router-1 received the Address query and responds back with AddressNotify. But still, the AddressQuery is buffered in the MPL buffers and sent twice which router-2 receives and sends it back to router-1. This would scale with more number of devices in the network and can cause a storm, especially in scenarios where Border router goes through a SW update and comes back up and all accessories try to resolve.

From receiver side logs:
01:57:02.451 [I] MeshForwarder-: Received IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]
01:57:02.451 [I] Platform------: MPL AddBufferedMessage: Sequence=0, SeedID=0xcc00, IsOutBound=false, buffer = 0x10531d720
01:57:02.451 [I] AddrResolver--: Received AddressQuery from 0xcc00 for target fdf0:fb06:268b:b7b9:752b:aa7e:cfcb:5210
2024-03-14 14:42:27.031641-0700 0x681 Info 0x0 79 0 threadradiod: [com.apple.openthread:default] 01:57:02.452 [I] AddrResolver--: Sent AddressNotify for target fdf0:fb06:268b:b7b9:752b:aa7e:cfcb:5210
01:57:02.476 [I] MeshForwarder-: Sent IPv6 UDP msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:a000]:61631, dst=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00]:61631

// MPL forwarding happens twice

01:57:02.485 [I] MeshForwarder-: Received IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]
01:57:02.518 [I] MeshForwarder-: Received IPv6 UDP msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00]:61631, dst=[fdf0:fb06:268b:b7b9:0:ff:fe00:a000]:61631

01:57:02.516 [I] MeshForwarder-: Sent IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]
01:57:02.591 [I] MeshForwarder-: Sent IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]

From sender side logs:

01:57:11.195 [I] AddrResolver--: Sent AddressQuery for fdf0:fb06:268b:b7b9:752b:aa7e:cfcb:5210
01:57:11.208 [I] MeshForwarder-: ITMD: Sent IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]
01:57:11.234 [I] AddrResolver--: Received AddressNotify from 0xa000 for fdf0:fb06:268b:b7b9:752b:aa7e:cfcb:5210 to 0xa000
01:57:11.235 [I] AddrResolver--: Sent AddressNotify ack
01:57:11.244 [I] MeshForwarder-: Sent IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]
01:57:11.281 [I] MeshForwarder-:Received IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]
01:57:11.351 [I] MeshForwarder-: Received IPv6 HopOpts msg, src=[fdf0:fb06:268b:b7b9:0:ff:fe00:cc00], dst=[ff03:0:0:0:0:0:0:2]

Additional context Add any other context about the problem here.

[jwhui]

All IPv6 multicast messages sent with scope greater than link-local are always forwarded by all Thread routers. This is also true for Address Query messages.

[sarveshkumarv3]

thanks @jwhui. In a topology with 1 border router and N routers, for every address query sent out, it would be received back 2N times. In scenarios where multiple address query gets triggered around same time, it can cause receive buffers to deplete and stuck in this state for some time? One scenario is software update of the border router, where all the other routers would detect the loss of link around the same time (if some periodic traffic from matter stack is ongoing and fails from the routers due to loss of link) causing address queries to be triggered around the same time. Also when we are in this state, no new parent request can be handled, which can lead to multiple partitions

11:39:21.364 [D] Mle-----------: Receive MLE message
11:39:21.365 [I] Mle-----------: Receive Parent Request (fe80:0:0:0:58b0:1cbf:6bbe:65f8)
11:39:21.365 [I] Message-------: No available message buffer
11:39:21.365 [W] Mle-----------: Failed to send Parent Response: NoBufs

One thought could be to mitigate this via the spec optimization to limit the first attempt of address query to 1-hop only, but that can still not guarantee we cannot get into this scenario? Can it be considered to limit the RX buffers for multicast traffic upto a certain limit or in other words, reserve some RX buffers exclusively for only unicast traffic?

[jwhui]

A Thread router should only forward a given IPv6 multicast message once - Thread routers track recently received IPv6 multicast messages and will not enqueue ones that were previously received.

Is there any way to get more visibility into the set of messages queued when there are no free buffers available?

[sarveshkumarv3]

Thanks for the feedback @jwhui, it looks like most of the buffers are occupied by the CoAP and not MPL (as I initially suspected). I am observing the below, around 50 seconds after the time of issue (I do not have visibility into the complete logs and exactly at the timepoint of issue).

total: 256
free: 0
max-used: 256
6lo send: 0 0 0
6lo reas: 0 0 0
ip6: 0 0 0
mpl: 0 0 0
mle: 0 0 0
coap: 253, 254, 29392
coap secure: 0 0 0
application coap: 0 0 0
Done

I do observe an underlying issue where AddressQuery is received from multiple accessories and the DUT responds with AddressNotify but I don't see the ACK for AddressNotify being received by the DUT and couldn't tell why without sniffer/accessory side logs. In this case, I think the buffer used by AddressNotify should be going through the max CoAP tx attempts(4) and eventually be freed, and looks like pretty much all buffers should have been occupied by AddressNotify. Eventually after around 1 minute the recovery happens, when I believe the AddressNotify buffers are freed after max retransmissions.

Address queries are received at a cadence which is faster than 16s from the accessories (couldn't tell why) and AddressNotify is triggered in response to that. Shouldn't there be a dedeuplication logic, if already an address notify is in retransmit state, the other address notify can be suppressed ( without queuing up in mPendingRequests)?

00:00:27.257 [I] AddrResolver--: Received AddressQuery from 0xe800 for target fd44:d730:ed29:f75:12a0:942d:c57:92ca
00:00:27.257 [I] AddrResolver--: Sent AddressNotify for target fd44:d730:ed29:f75:12a0:942d:c57:92ca
00:00:27.631 [I] AddrResolver--: Received AddressQuery from 0xe800 for target fd44:d730:ed29:f75:12a0:942d:c57:92ca
00:00:27.631 [I] AddrResolver--: Sent AddressNotify for target fd44:d730:ed29:f75:12a0:942d:c57:92ca
00:00:27.635 [I] AddrResolver--: Received AddressQuery from 0x8400 for target fd44:d730:ed29:f75:12a0:942d:c57:92ca
00:00:27.635 [I] AddrResolver--: Sent AddressNotify for target fd44:d730:ed29:f75:12a0:942d:c57:92ca
00:00:27.844 [I] AddrResolver--: Received AddressQuery from 0x8400 for target fd44:d730:ed29:f75:12a0:942d:c57:92ca
00:00:27.844 [I] AddrResolver--: Sent AddressNotify for target fd44:d730:ed29:f75:12a0:942d:c57:92ca 

[sarveshkumarv3]

Had a few questions regarding the current eviction rules and asked in this thread . Thanks

[abtink]

Address queries are received at a cadence which is faster than 16s from the accessories (couldn't tell why)

Would be great to understand the reason behind this better.
The retx logic for address query starts at 16 seconds interval

If already an address notify is in retransmit state, the other address notify can be suppressed ( without queuing up in mPendingRequests)?

This would be a safeguard against excessive address queries (which itself warrant further investigation).

• I'm not sure how straightforward implementation will be.
  • The CoAP module, by design, is agnostic to message content.
  • This means we'll need to introduce a mechanism to parse pending TMF requests to identify potential match to a new Address Notification.
• This adds complexity (and code size overhead) to address a specific situation (excessive queries without timely CoAP acknowledgments for TMF Address Notification from same sender).

[sarveshkumarv3]

Address queries are received at a cadence which is faster than 16s from the accessories (couldn't tell why)

Would be great to understand the reason behind this better. The retx logic for address query starts at 16 seconds interval

I don't have the logs from accessory but I suspect the matter stack at accessory could be causing a crash loop leading to this behavior

If already an address notify is in retransmit state, the other address notify can be suppressed ( without queuing up in mPendingRequests)?

This would be a safeguard against excessive address queries (which itself warrant further investigation).

• I'm not sure how straightforward implementation will be.

  • The CoAP module, by design, is agnostic to message content.
  • This means we'll need to introduce a mechanism to parse pending TMF requests to identify potential match to a new Address Notification.

• This adds complexity (and code size overhead) to address a specific situation (excessive queries without timely CoAP acknowledgments for TMF Address Notification from same sender).

This sounds good idea to me, similar to deduplication logic in response queue, but I also feel it would be complex to implement

[caipiblack]

Hello,

I have a problem but I don't really know if it can be related to this issue.

My problems seems to appear when we turn off our Thread border router and the devices and when we turn them on. When the problem appear: The commissioning of Matter devices seems to fail, it seems to be related to AddressQuery AddressNotify:

2024-04-04T10:44:55.380002+02:00 otbr-agent[2625]: 01:10:31.074 [I] AddrResolver--: Sent AddressQuery for fd76:41a4:8735:1:f6e9:16c9:78a1:2711
2024-04-04T10:44:58.219066+02:00 otbr-agent[2625]: 01:10:33.913 [I] AddrResolver--: Timed out waiting for AddressNotify for fd76:41a4:8735:1:f6e9:16c9:78a1:2711, retry: 120
2024-04-04T10:44:58.219234+02:00 otbr-agent[2625]: 01:10:33.914 [N] MeshForwarder-: Dropping IPv6 UDP msg, len:252, chksum:ef7c, ecn:no, sec:yes, error:AddressQuery, prio:low, radio:all
2024-04-04T10:44:58.219281+02:00 otbr-agent[2625]: 01:10:33.914 [N] MeshForwarder-:     src:[fd76:41a4:8735:1:df67:782f:d195:6b1c]:43672
2024-04-04T10:44:58.219320+02:00 otbr-agent[2625]: 01:10:33.914 [N] MeshForwarder-:     dst:[fd76:41a4:8735:1:f6e9:16c9:78a1:2711]:5540
2024-04-04T10:45:01.365165+02:00 otbr-agent[2625]: 01:10:37.059 [N] MeshForwarder-: Dropping IPv6 UDP msg, len:252, chksum:ef7c, ecn:no, sec:yes, error:Drop, prio:low, radio:all
2024-04-04T10:45:01.365319+02:00 otbr-agent[2625]: 01:10:37.060 [N] MeshForwarder-:     src:[fd76:41a4:8735:1:df67:782f:d195:6b1c]:43672
2024-04-04T10:45:01.365372+02:00 otbr-agent[2625]: 01:10:37.060 [N] MeshForwarder-:     dst:[fd76:41a4:8735:1:f6e9:16c9:78a1:2711]:5540

Just AddrResolver :

2024-04-04T10:42:27.948619+02:00 otbr-agent[2625]: 01:08:03.646 [I] AddrResolver--: Received AddressQuery from 0x8800 for target fdc5:9445:74e:3d8b:8542:45bc:27ae:5314
2024-04-04T10:42:27.948669+02:00 otbr-agent[2625]: 01:08:03.646 [I] AddrResolver--: Sent AddressNotify for target fdc5:9445:74e:3d8b:8542:45bc:27ae:5314
2024-04-04T10:42:39.236851+02:00 otbr-agent[2625]: 01:08:14.932 [I] AddrResolver--: Ramping down fd76:41a4:8735:1:f6e9:16c9:78a1:2711 retry-delay:60
2024-04-04T10:42:57.007625+02:00 otbr-agent[2625]: 01:08:32.703 [I] AddrResolver--: Received AddressQuery from 0x7003 for target fdc5:9445:74e:3d8b:8542:45bc:27ae:5314
2024-04-04T10:42:57.007667+02:00 otbr-agent[2625]: 01:08:32.703 [I] AddrResolver--: Sent AddressNotify for target fdc5:9445:74e:3d8b:8542:45bc:27ae:5314
2024-04-04T10:42:57.067919+02:00 otbr-agent[2625]: 01:08:32.764 [I] AddrResolver--: Cache entry added: fdc5:9445:74e:3d8b:c2d0:cded:e752:88db, 0x7003 - snoop
2024-04-04T10:42:58.145931+02:00 otbr-agent[2625]: 01:08:33.841 [I] AddrResolver--: Sent AddressQuery for fd76:41a4:8735:1:f6e9:16c9:78a1:2711
2024-04-04T10:42:59.243162+02:00 otbr-agent[2625]: 01:08:34.938 [I] AddrResolver--: Sent AddressQuery for fd76:41a4:8735:1:95c9:531e:3953:4dad
2024-04-04T10:42:59.243338+02:00 otbr-agent[2625]: 01:08:34.939 [I] AddrResolver--: Cache entry added: fd76:41a4:8735:1:95c9:531e:3953:4dad, 0xfffe - query request
2024-04-04T10:42:59.299272+02:00 otbr-agent[2625]: 01:08:34.996 [I] AddrResolver--: Received AddressNotify from 0x7003 for fd76:41a4:8735:1:95c9:531e:3953:4dad to 0x7003
2024-04-04T10:42:59.299313+02:00 otbr-agent[2625]: 01:08:34.996 [I] AddrResolver--: Cache entry updated: fd76:41a4:8735:1:95c9:531e:3953:4dad, 0x7003 - rx notification
2024-04-04T10:42:59.299352+02:00 otbr-agent[2625]: 01:08:34.996 [I] AddrResolver--: Sent AddressNotify ack
2024-04-04T10:43:00.234343+02:00 otbr-agent[2625]: 01:08:35.931 [I] AddrResolver--: Timed out waiting for AddressNotify for fd76:41a4:8735:1:f6e9:16c9:78a1:2711, retry: 60
2024-04-04T10:43:06.519023+02:00 otbr-agent[2625]: 01:08:42.216 [I] AddrResolver--: Cache entry removed: fd76:41a4:8735:1:b96c:2ee5:e192:1203, 0x8800, list:cached - removing router id
2024-04-04T10:43:06.519077+02:00 otbr-agent[2625]: 01:08:42.216 [I] AddrResolver--: Cache entry removed: fdc5:9445:74e:3d8b:3cf5:e457:2530:c10a, 0x8800, list:cached - removing router id
2024-04-04T10:43:07.185128+02:00 otbr-agent[2625]: 01:08:42.880 [I] AddrResolver--: Sent AddressQuery for fd76:41a4:8735:1:b96c:2ee5:e192:1203
2024-04-04T10:43:07.185303+02:00 otbr-agent[2625]: 01:08:42.881 [I] AddrResolver--: Cache entry added: fd76:41a4:8735:1:b96c:2ee5:e192:1203, 0xfffe - query request
2024-04-04T10:43:09.238068+02:00 otbr-agent[2625]: 01:08:44.933 [I] AddrResolver--: Timed out waiting for AddressNotify for fd76:41a4:8735:1:b96c:2ee5:e192:1203, retry: 15
2024-04-04T10:43:24.230173+02:00 otbr-agent[2625]: 01:08:59.925 [I] AddrResolver--: Starting ramp down of fd76:41a4:8735:1:b96c:2ee5:e192:1203 retry-delay:120
2024-04-04T10:43:26.544520+02:00 otbr-agent[2625]: 01:09:02.240 [I] AddrResolver--: Cache entry removed: fdc5:9445:74e:3d8b:c2d0:cded:e752:88db, 0x7003, list:cached - removing rloc16
2024-04-04T10:43:26.544561+02:00 otbr-agent[2625]: 01:09:02.240 [I] AddrResolver--: Cache entry removed: fd76:41a4:8735:1:95c9:531e:3953:4dad, 0x7003, list:cached - removing rloc16
2024-04-04T10:44:00.233592+02:00 otbr-agent[2625]: 01:09:35.928 [I] AddrResolver--: Starting ramp down of fd76:41a4:8735:1:f6e9:16c9:78a1:2711 retry-delay:120
2024-04-04T10:44:55.380002+02:00 otbr-agent[2625]: 01:10:31.074 [I] AddrResolver--: Sent AddressQuery for fd76:41a4:8735:1:f6e9:16c9:78a1:2711
2024-04-04T10:44:58.219066+02:00 otbr-agent[2625]: 01:10:33.913 [I] AddrResolver--: Timed out waiting for AddressNotify for fd76:41a4:8735:1:f6e9:16c9:78a1:2711, retry: 120
2024-04-04T10:45:24.221900+02:00 otbr-agent[2625]: 01:10:59.916 [I] AddrResolver--: Ramping down fd76:41a4:8735:1:b96c:2ee5:e192:1203 retry-delay:15
2024-04-04T10:46:58.214855+02:00 otbr-agent[2625]: 01:12:33.908 [I] AddrResolver--: Starting ramp down of fd76:41a4:8735:1:f6e9:16c9:78a1:2711 retry-delay:120
2024-04-04T10:48:03.968373+02:00 otbr-agent[2625]: 01:13:39.663 [I] AddrResolver--: Sent AddressQuery for fd76:41a4:8735:1:95c9:531e:3953:4dad
2024-04-04T10:48:03.968522+02:00 otbr-agent[2625]: 01:13:39.663 [I] AddrResolver--: Cache entry added: fd76:41a4:8735:1:95c9:531e:3953:4dad, 0xfffe - query request
2024-04-04T10:48:06.225754+02:00 otbr-agent[2625]: 01:13:41.919 [I] AddrResolver--: Timed out waiting for AddressNotify for fd76:41a4:8735:1:95c9:531e:3953:4dad, retry: 15

More logs here: dropping_logs.txt

Is it related ?

[jwhui]

@caipiblack , what you shared does not appear to be the same issue.

Address Queries to fd76:41a4:8735:1:f6e9:16c9:78a1:2711 are repeatedly failing. It seems that destination is not reachable.

Address Queries to other destinations (e.g. fd76:41a4:8735:1:95c9:531e:3953:4dad) are succeeding.

Looking at your logs, it seems 802.15.4 radio transmissions are failing:

2024-04-04T10:43:05.061736+02:00 otbr-agent[2625]: 01:08:40.758 [I] Mac-----------: Frame tx attempt 16/16 failed, error:NoAck, len:122, seqnum:250, type:Data, src:0x7000, dst:0x8800, sec:yes, ackreq:yes, radio:15.4
2024-04-04T10:43:05.061901+02:00 otbr-agent[2625]: 01:08:40.758 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:116, chksum:9dfe, ecn:no, to:0x8800, sec:yes, error:NoAck, prio:low, radio:15.4
2024-04-04T10:43:05.488969+02:00 otbr-agent[2625]: 01:08:41.185 [I] Mac-----------: Frame tx attempt 16/16 failed, error:NoAck, len:122, seqnum:251, type:Data, src:0x7000, dst:0x8800, sec:yes, ackreq:yes, radio:15.4
2024-04-04T10:43:05.489190+02:00 otbr-agent[2625]: 01:08:41.186 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:116, chksum:9dfe, ecn:no, to:0x8800, sec:yes, error:NoAck, prio:low, radio:15.4
2024-04-04T10:43:05.907753+02:00 otbr-agent[2625]: 01:08:41.603 [I] Mac-----------: Frame tx attempt 16/16 failed, error:NoAck, len:122, seqnum:252, type:Data, src:0x7000, dst:0x8800, sec:yes, ackreq:yes, radio:15.4
2024-04-04T10:43:05.907938+02:00 otbr-agent[2625]: 01:08:41.603 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:116, chksum:9dfe, ecn:no, to:0x8800, sec:yes, error:NoAck, prio:low, radio:15.4
2024-04-04T10:43:06.518868+02:00 otbr-agent[2625]: 01:08:42.215 [I] Mac-----------: Frame tx attempt 16/16 failed, error:NoAck, len:122, seqnum:253, type:Data, src:0x7000, dst:0x8800, sec:yes, ackreq:yes, radio:15.4
2024-04-04T10:43:06.519120+02:00 otbr-agent[2625]: 01:08:42.216 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:116, chksum:9dfe, ecn:no, to:0x8800, sec:yes, error:NoAck, prio:low, radio:15.4
2024-04-04T10:47:47.369648+02:00 otbr-agent[2625]: 01:13:23.064 [I] Mac-----------: Frame tx attempt 16/16 failed, error:NoAck, len:80, seqnum:29, type:Data, src:2e2b39c61086b904, dst:ce3675a9d79f2163, sec:no, ackreq:yes, radio:15.4
2024-04-04T10:47:47.369775+02:00 otbr-agent[2625]: 01:13:23.065 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:8e49, ecn:no, to:ce3675a9d79f2163, sec:no, error:NoAck, prio:net, radio:15.4
2024-04-04T10:47:48.382760+02:00 otbr-agent[2625]: 01:13:24.077 [I] Mac-----------: Frame tx attempt 16/16 failed, error:NoAck, len:80, seqnum:30, type:Data, src:2e2b39c61086b904, dst:ce3675a9d79f2163, sec:no, ackreq:yes, radio:15.4
2024-04-04T10:47:48.382937+02:00 otbr-agent[2625]: 01:13:24.078 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:8abe, ecn:no, to:ce3675a9d79f2163, sec:no, error:NoAck, prio:net, radio:15.4
2024-04-04T10:47:49.389612+02:00 otbr-agent[2625]: 01:13:25.084 [I] Mac-----------: Frame tx attempt 16/16 failed, error:NoAck, len:80, seqnum:31, type:Data, src:2e2b39c61086b904, dst:ce3675a9d79f2163, sec:no, ackreq:yes, radio:15.4
2024-04-04T10:47:49.389740+02:00 otbr-agent[2625]: 01:13:25.085 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:96, chksum:b6bf, ecn:no, to:ce3675a9d79f2163, sec:no, error:NoAck, prio:net, radio:15.4

[jwhui]

@sarveshkumarv3

I don't have the logs from accessory but I suspect the matter stack at accessory could be causing a crash loop leading to this behavior

Ideally, we can root cause this issue. Is there a reproducible test scenario that exhibits the Address Query behavior that you are observing?

[sarveshkumarv3]

@jwhui it is not clear to me yet, I have only seen 1 occurrence of this issue so far. There were few instances where the matter stack at the test accessory was running out of buffers and causing a kernel panic, and I was suspecting this could lead to the observed behavior, but attempts to reproduce this issue were futile. Will check further and update.

What is the use case for invoking RestartAddressQueries from Mle::Start via SetRloc16? Wondering if this could exhibit this symptom, as I see this as one place where AddressQuery could be sent out before Attach procedure initiates ( if query list is non-empty)?

[jwhui]

What is the use case for invoking RestartAddressQueries from Mle::Start via SetRloc16? Wondering if this could exhibit this symptom, as I see this as one place where AddressQuery could be sent out before Attach procedure initiates ( if query list is non-empty)?

When an FTD changes its RLOC (e.g. due to switching between child and router roles), any existing Address Query transaction will fail. Restarting allows it to continue forwarding any queued messages again.