Address query fail on TREL

[fgervais]

I have a Thread network with 2 border routers using TREL as follow:

         +--------+
         |        |
         | Server |
         |        |
         +----+---+
              |
              |
              |
              |
              |
              |                                                          Ethernet Network
--------------+-------------+--------------------------------------+----------------------
                            |                                      |
                            |                                      |
                            |                                      |
                      +-----+-----+                          +-----+-----+
                      |           |                          |           |
                      |    BR1    |                          |    BR2    |
                      |           |                          |           |
                      +-----+-----+                          +-----+-----+
                            |                                      |
                            |                                      |
                            |                                      |
                    +-------+-------+                      +-------+-------+
                    |               |                      |               |
                    |  Thread Mesh  |                      |  Thread Mesh  |
                    |               |                      |               |
                    +---------------+                      +-------+-------+
                                                                   |
                                                                   |
                                                                   |
                                                               +---+----+
                                                               |        |
                                                               |  FTD1  |
                                                               |        |
                                                               +--------+

Note1: The Server has a static route to the mesh prefix (fd04:2240:0:102::/64) through BR1.

The scenario is:

1. FTD1 sends a query to Server
2. Query reaches Server
3. Server answer through BR1
4. BR1 doesn't know about the FTD1 address so sends an address query to ff03::2
5. Not sure what happens with this request exactly
6. BR1 times out address query
7. BR1 drops frames for FTD1

Logs on BR1:

Any idea where I should look to track down this issue?

[jwhui]

Are BR1 and BR2 connected via the same Thread topology? The output of the following commands should provide some more visibility:

• neighbor table
• trel peers

[abtink]

They trel peers show that have different EXT PAN ID dead00beef00cafe and 4224000000001000, so the two nodes are not considered to be part of same Thread network and would not talk to each other over trel link.

Here are some things to investigate:

• Did the two nodes set up to be part of the same network (do they have same EXT PAN ID?)?
• If they have the same ext pan id, next question would be if/how the advertised trel service does not reflect it? Maybe something went wrong when publishing the trel service on infra-link mdns (e.g., TXT entries did not get correctly updated and/or old xpanid value is being cached/used?)

[fgervais]

Yes this is because, when I configure the network, I do the following:

1. I start BR1, it is in factory state, I set it up
2. I start BR2 which is also in factory state.
3. The first time BR1 sees BR2, it is in it's factory default state (hence the dead00beef00cafe EXT PAN ID in TREL peers info).
4. I setup BR2 the same as BR1.
5. The TREL peers info is stuck to the factory info for BR2. Although I'm not sure if it actually affect the network.

[fgervais]

You can see they actually have the same config:

BR1:

fgervais@nuc2:~$ docker exec -it `docker ps -f name=autostart-otbr --format '{{.ID}}'` ot-ctl dataset active
Active Timestamp: 1
Channel: 15
Channel Mask: 0x07fff800
Ext PAN ID: 4224000000001000
Mesh Local Prefix: fdb5:341:c736:7c8d::/64
Network Key: [...]
Network Name: home
PAN ID: 0x2240
PSKc: [...]
Security Policy: 672 onrc
Done

BR2:

fgervais@otbr2:~$ docker exec -it `docker ps -f name=autostart-otbr --format '{{.ID}}'` ot-ctl dataset active
Active Timestamp: 1
Channel: 15
Channel Mask: 0x07fff800
Ext PAN ID: 4224000000001000
Mesh Local Prefix: fdb5:341:c736:7c8d::/64
Network Key: [...]
Network Name: home
PAN ID: 0x2240
PSKc: [...]
Security Policy: 672 onrc
Done

[abtink]

The TREL peers info is stuck to the factory info for BR2. Although I'm not sure if it actually affect the network.

This is the main issue.

After BR2 changes it network (dataset) it should start advertising "trel service" on mDNS using the new info (as part of the TXT data of trel service). The question is why is this not happening?

• I know OT code will request this using otPlatTrelRegisterService() platform API (which passes the new TXT records).
• This is triggered on xpan id changes
  

  openthread/src/core/radio/trel_interface.cpp

  Lines 122 to 140 in 5f8f05c

  	void Interface::HandleExtAddressChange(void)
  	{
  	VerifyOrExit(mInitialized && mEnabled);
  	LogDebg("Extended Address changed, re-registering DNS-SD service");
  	mRegisterServiceTask.Post();
  	exit:
  	return;
  	}
  	void Interface::HandleExtPanIdChange(void)
  	{
  	VerifyOrExit(mInitialized && mEnabled);
  	LogDebg("Extended PAN ID changed, re-registering DNS-SD service");
  	mRegisterServiceTask.Post();
  	exit:
  	return;
  	}

The other aspect can be that the other node does not correctly discover and/or report when TXT data gets changed for an existing mDNS service (somehow reports the old TXT data or ... ?). If this is the case, then it is a platform issue.

[fgervais]

Thank you I will have a look.