[question] Switching with/without ethernet interface connected

[caipiblack]

Hello,

We have a IOT gateway running on Yocto with ethernet and wifi interface working good since a long time with otbr-agent.

Except one case: When we have no ethernet/wifi connection.

The functional cases are:

WiFi	Ethernet	Usage
connected	disconnected	Access thread network from the gateway + External access through 'ethernet' interface (border router)
disconnected	connected	Access thread network from the gateway + External access through 'mlan0' interface (border router)
disconnected	disconnected	Access thread network from the gateway

Up to now we was starting otbr-agent like this:

THREAD_IF="wpan0"
DEFAULT_IF=$(/usr/bin/get-prefered-if)
/usr/sbin/otbr-agent -I "${THREAD_IF}" -B "${DEFAULT_IF}" "spinel+cpc://cpcd_0?iid=2&iid-list=0"

But as otbr-agent have troubles when Ethernet AND WiFi interfaces are disconnected, we are thinking about removing the -B option

We are not sure to really understand what is this option for:

• Is it to make the border router routing to this interface ?
• Or is it something else ? (what is backbone interface (?))

We don't know if it's a good idea or not to:

• Put this option when Ethernet or WiFi is connected
• Remove this option if Ethernet and WiFi are disconnected

Also we found something strange:

• When we don't configure -B option and we have no ethernet/wifi connection: we can ping a thread device from the IOT Gateway
• When we don't configure -B option and we connect an ethernet cable, the ping start to fail because (probably) the IPv6 source address of the ping request is taken from Ethernet interface instead of wpan0,

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: ethernet: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:01:24:23:00:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global ethernet
       valid_lft forever preferred_lft forever
    inet 192.168.20.187/24 metric 10 brd 192.168.20.255 scope global dynamic ethernet
       valid_lft 80449sec preferred_lft 80449sec
    inet6 fda7:e557:971d:7bd:1:24ff:fe23:20/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 1664sec preferred_lft 1664sec
    inet6 fe80::1:24ff:fe23:20/64 scope link 
       valid_lft forever preferred_lft forever
4: mlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 50:5a:65:f2:3a:7f brd ff:ff:ff:ff:ff:ff
5: uap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 50:5a:65:f2:3b:7f brd ff:ff:ff:ff:ff:ff
6: p2p0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 52:5a:65:f2:3a:7f brd ff:ff:ff:ff:ff:ff
9: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet6 fd9e:148d:d218:f464:0:ff:fe00:fc00/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd9e:148d:d218:f464:0:ff:fe00:2c00/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd9e:148d:d218:f464:7931:c265:4bbf:3449/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::9059:adc3:c93a:111a/64 scope link nodad 
       valid_lft forever preferred_lft forever

ipaddr on a thread CLI device:

> ipaddr
fd9e:148d:d218:f464:0:ff:fe00:cc00
fd9e:148d:d218:f464:a0db:3182:8b48:ae8
fe80:0:0:0:a0e5:221b:556d:b95f
Done

The ping from the computer when ethernet is connected (without -B):

# ping fd9e:148d:d218:f464:0:ff:fe00:cc00
PING fd9e:148d:d218:f464:0:ff:fe00:cc00 (fd9e:148d:d218:f464:0:ff:fe00:cc00): 56 data bytes
...timeout...

Logs when otbr-agent is started without -B AND ethernet cable is connected:

# ot-ctl ipaddr
fd9e:148d:d218:f464:0:ff:fe00:fc00
fd9e:148d:d218:f464:0:ff:fe00:2c00
fd9e:148d:d218:f464:7931:c265:4bbf:3449
fe80:0:0:0:9059:adc3:c93a:111a
Done
# ot-ctl netdata show
Prefixes:
Routes:
Services:
Contexts:
Done
# ot-ctl state
leader
Done

Feb 13 13:02:01 otbr-agent[7491]: 01:39:32.542 [N] MeshForwarder-: (exit) mac state: 0, sub_mac state: 2
Feb 13 13:02:01 otbr-agent[7491]: 01:39:32.570 [I] MeshForwarder-: Sent IPv6 ICMP6 msg, len:104, chksum:7981, ecn:no, to:0xcc00, sec:yes, prio:low, radio:15.4
Feb 13 13:02:01 otbr-agent[7491]: 01:39:32.570 [I] MeshForwarder-:     src:[fda7:e557:971d:7bd:1:24ff:fe23:20]
Feb 13 13:02:01 otbr-agent[7491]: 01:39:32.570 [I] MeshForwarder-:     dst:[fd9e:148d:d218:f464:0:ff:fe00:cc00]
// No response on the ping request, using from IPv6 source

Logs when otbr-agent is started without -B AND ethernet cable is disconnected:

# ot-ctl state
leader
Done
# ot-ctl ipaddr
fd9e:148d:d218:f464:0:ff:fe00:fc00
fd9e:148d:d218:f464:0:ff:fe00:2c00
fd9e:148d:d218:f464:7931:c265:4bbf:3449
fe80:0:0:0:9059:adc3:c93a:111a
Done
# ot-ctl netdata show
Prefixes:
Routes:
Services:
Contexts:
Done

Feb 13 13:09:15 otbr-agent[7491]: 01:46:46.388 [I] MeshForwarder-: Sent IPv6 ICMP6 msg, len:104, chksum:a600, ecn:no, to:0xcc00, sec:yes, prio:low, radio:15.4
Feb 13 13:09:15 otbr-agent[7491]: 01:46:46.388 [I] MeshForwarder-:     src:[fd9e:148d:d218:f464:0:ff:fe00:fc00]
Feb 13 13:09:15 otbr-agent[7491]: 01:46:46.388 [I] MeshForwarder-:     dst:[fd9e:148d:d218:f464:0:ff:fe00:cc00]
Feb 13 13:09:15 otbr-agent[7491]: 01:46:46.402 [I] MeshForwarder-: Received IPv6 ICMP6 msg, len:104, chksum:a500, ecn:no, from:0xcc00, sec:yes, prio:normal, rss:-54.0, radio:15.4
Feb 13 13:09:15 otbr-agent[7491]: 01:46:46.402 [I] MeshForwarder-:     src:[fd9e:148d:d218:f464:0:ff:fe00:cc00]
Feb 13 13:09:15 otbr-agent[7491]: 01:46:46.402 [I] MeshForwarder-:     dst:[fd9e:148d:d218:f464:0:ff:fe00:fc00]
// The ping is working well

Also, is there a better place for this kind of questions ? Like a chat or something.

[superwhd]

Is it to make the border router routing to this interface ?

Border routing is part of what it does. Service discovery will also happen on this interface. If you remove this option, otbr-agent will operate as a Thread-only device instead of a Thread Border Router.

When you have multiple potential infra (backbone) links available, I think you should consider specifying multiple -B options then otbr-agent will decide which to use. When your infra link status changes (e.g. ethernet goes down and WiFi is up), it will get notified and will evaluate which infra link to use. If it decides to switch to another link, the otbr-agent process will restart and use the new link.

Reference: https://github.com/openthread/ot-br-posix/blob/main/src/utils/infra_link_selector.cpp

IIUC the problem you met is that your BR cannot ping a Thread device when your BR is not connected to WiFi or Ethernet? Per you mentioned that it auto selected an address on the Ethernet interface, it may indicate something is wrong in your Linux routing table.

It'll be helpful if you provide following information.

$ ip -6 route show table all
$ ip -6 rule
$ ip route get <Thread destination>

Also, is there a better place for this kind of questions ? Like a chat or something.

I think GitHub issues is the suggested place for such discussions.

[caipiblack]

Thanks,

We are going to check about using multiple -B options and compare with our current solution to see the benefits/problems of this solution.

(Currently we have a script that stop otbr-agent everytime a network switch is operated and start it using the "prefered interface" (interface that is connected / prefered interface if the two are connected)"

It's good to know that otbr-agent is supposed to work as a thread device without -B, so that in theory it's possible to work without ethernet/wifi interfaces.

Also, I don't know if it's important, but the 'wrong' IPv6 address that is affected to eth0 and used as 'source address' when we use otbr-agent without '-B' is possibly comming from another border router (as we run multiple border routers in the network!)

Maybe next week I will check for IPv6 routes and confirm or not the previous line. Then I will post the result here.

[caipiblack]

Hello,

I have reproduced the situation where:

• otbr-agent is started without the -B option (because we don't want to work as border router)
• Ethernet cable is connected
• The ping of a thread device fail because it takes the wrong IPv6 source!

This is the result of the commands and it's very interesting:

The ping is failing like this:

# ping fd9e:148d:d218:f464:0:ff:fe00:c000 -c 1
PING fd9e:148d:d218:f464:0:ff:fe00:c000 (fd9e:148d:d218:f464:0:ff:fe00:c000): 56 data bytes
Feb 24 11:02:23 otbr-agent[2254]: 00:01:45.520 [N] MeshForwarder-: (exit) mac state: 0, sub_mac state: 2
Feb 24 11:02:23 otbr-agent[2254]: 00:01:45.547 [I] MeshForwarder-: Sent IPv6 ICMP6 msg, len:104, chksum:167b, ecn:no, to:0xc000, sec:yes, prio:low, radio:15.4
Feb 24 11:02:23 otbr-agent[2254]: 00:01:45.548 [I] MeshForwarder-:     src:[fdf3:54e7:4f05:0:0:0:0:ad9]
Feb 24 11:02:23 otbr-agent[2254]: 00:01:45.548 [I] MeshForwarder-:     dst:[fd9e:148d:d218:f464:0:ff:fe00:c000]

As we can see here, the source IPv6 is wrong! It takes the IPv6 of "ethernet" interface (see below)

Interfaces:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: ethernet: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:01:24:23:00:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global ethernet
       valid_lft forever preferred_lft forever
    inet 192.168.3.100/24 metric 10 brd 192.168.3.255 scope global dynamic ethernet
       valid_lft 42951sec preferred_lft 42951sec
    inet6 fdf3:54e7:4f05::ad9/128 scope global dynamic noprefixroute 
       valid_lft 42953sec preferred_lft 42953sec
    inet6 fdf3:54e7:4f05:0:1:24ff:fe23:20/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 4294967048sec preferred_lft 4294967048sec
    inet6 fe80::1:24ff:fe23:20/64 scope link 
       valid_lft forever preferred_lft forever
4: mlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 50:5a:65:f2:3a:7f brd ff:ff:ff:ff:ff:ff
5: uap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 50:5a:65:f2:3b:7f brd ff:ff:ff:ff:ff:ff
6: p2p0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 52:5a:65:f2:3a:7f brd ff:ff:ff:ff:ff:ff
9: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet6 fd9e:148d:d218:f464:0:ff:fe00:fc00/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd9e:148d:d218:f464:0:ff:fe00:2c00/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd9e:148d:d218:f464:7931:c265:4bbf:3449/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::9059:adc3:c93a:111a/64 scope link nodad 
       valid_lft forever preferred_lft forever

Some commands:

# ip -6 route show table all
local ::1 dev lo proto kernel metric 0 pref medium
::1 dev lo proto kernel metric 256 pref medium
anycast fd9e:148d:d218:f464:: dev wpan0 proto kernel metric 0 pref medium
local fd9e:148d:d218:f464:0:ff:fe00:2c00 dev wpan0 proto kernel metric 0 pref medium
local fd9e:148d:d218:f464:0:ff:fe00:fc00 dev wpan0 proto kernel metric 0 pref medium
local fd9e:148d:d218:f464:7931:c265:4bbf:3449 dev wpan0 proto kernel metric 0 pref medium
fd9e:148d:d218:f464::/64 dev wpan0 proto kernel metric 256 pref medium
anycast fdf3:54e7:4f05:: dev ethernet proto kernel metric 0 pref medium
local fdf3:54e7:4f05::ad9 dev ethernet proto kernel metric 0 pref medium
local fdf3:54e7:4f05:0:1:24ff:fe23:20 dev ethernet proto kernel metric 0 pref medium
fdf3:54e7:4f05::/64 dev ethernet proto ra metric 10 pref medium
fdf3:54e7:4f05::/64 dev ethernet proto kernel metric 256 pref medium
unreachable fdf3:54e7:4f05:8::/62 dev lo proto dhcp metric 1024 pref medium
fdf3:54e7:4f05::/48 via fe80::6238:e0ff:fecd:9268 dev ethernet proto ra metric 10 expires 1630sec pref medium
anycast fe80:: dev ethernet proto kernel metric 0 pref medium
anycast fe80:: dev wpan0 proto kernel metric 0 pref medium
local fe80::1:24ff:fe23:20 dev ethernet proto kernel metric 0 pref medium
local fe80::9059:adc3:c93a:111a dev wpan0 proto kernel metric 0 pref medium
fe80::/64 dev ethernet proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium
ff02::fb dev lo metric 1024 pref medium
multicast ff00::/8 dev ethernet proto kernel metric 256 pref medium
multicast ff00::/8 dev wpan0 proto kernel metric 256 pref medium
default dev ethernet proto static metric 1024 onlink pref medium


# ip -6 rule
RTNETLINK answers: Address family not supported by protocol
Dump terminated


# ip route get fd9e:148d:d218:f464:0:ff:fe00:c000
fd9e:148d:d218:f464:0:ff:fe00:c000 dev wpan0 proto kernel src fdf3:54e7:4f05::ad9 metric 256 pref medium


# ot-ctl ipaddr
fd9e:148d:d218:f464:0:ff:fe00:fc00
fd9e:148d:d218:f464:0:ff:fe00:2c00
fd9e:148d:d218:f464:7931:c265:4bbf:3449
fe80:0:0:0:9059:adc3:c93a:111a
Done


# ot-ctl netdata show
Prefixes:
Routes:
Services:
Contexts:
Done

# ot-ctl state
leader
Done

If I run this command, the ping start to work:

ip addr flush dev ethernet

Ping:

# ping fd9e:148d:d218:f464:0:ff:fe00:c000 -c 1
PING fd9e:148d:d218:f464:0:ff:fe00:c000 (fd9e:148d:d218:f464:0:ff:fe00:c000): 56 data bytes
64 bytes from fd9e:148d:d218:f464:0:ff:fe00:c000: seq=0 ttl=64 time=39.853 ms

--- fd9e:148d:d218:f464:0:ff:fe00:c000 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 39.853/39.853/39.853 ms

Feb 24 12:24:03 otbr-agent[2254]: 01:23:25.799 [N] MeshForwarder-: (exit) mac state: 0, sub_mac state: 2
Feb 24 12:24:03 otbr-agent[2254]: 01:23:25.824 [I] MeshForwarder-: Sent IPv6 ICMP6 msg, len:104, chksum:df7f, ecn:no, to:0xc000, sec:yes, prio:low, radio:15.4
Feb 24 12:24:03 otbr-agent[2254]: 01:23:25.824 [I] MeshForwarder-:     src:[fd9e:148d:d218:f464:0:ff:fe00:fc00]
Feb 24 12:24:03 otbr-agent[2254]: 01:23:25.824 [I] MeshForwarder-:     dst:[fd9e:148d:d218:f464:0:ff:fe00:c000]
Feb 24 12:24:03 otbr-agent[2254]: 01:23:25.837 [I] MeshForwarder-: Received IPv6 ICMP6 msg, len:104, chksum:de7f, ecn:no, from:0xc000, sec:yes, prio:normal, rss:-52.0, radio:15.4
Feb 24 12:24:03 otbr-agent[2254]: 01:23:25.837 [I] MeshForwarder-:     src:[fd9e:148d:d218:f464:0:ff:fe00:c000]
Feb 24 12:24:03 otbr-agent[2254]: 01:23:25.837 [I] MeshForwarder-:     dst:[fd9e:148d:d218:f464:0:ff:fe00:fc00]

And the prefered route has changed:

# ip route get fd9e:148d:d218:f464:0:ff:fe00:c000
fd9e:148d:d218:f464:0:ff:fe00:c000 dev wpan0 proto kernel src fd9e:148d:d218:f464:0:ff:fe00:fc00 metric 256 pref medium

So at this point, the problem seems to be related to:

• The IPv6 addresses that are present on ethernet interface (I don't know where they come from, possibly another border router on the network)
• The routes that are not correct or similar so there is a confusion (?)

Did you know why it takes this route:

local fdf3:54e7:4f05::ad9 dev ethernet proto kernel metric 0 pref medium

Instead of this one:

local fd9e:148d:d218:f464:0:ff:fe00:fc00 dev wpan0 proto kernel metric 0 pref medium

To access fd9e:148d:d218:f464:0:ff:fe00:c000 on wpan0 ?

Is there a way to force it using wpan0 in any cases to access thread network ?

Note that when we create the thread network, we don't use this command:

ot-ctl prefix add XXXXXXXXXX paros med

In the past we had issues with this command, possibly because we had multiple iot hubs with same prefix (not completely sure). Is it related ?

[caipiblack]

Hello,

This is just to say that I solved the main issue like this:

1. Activate some configurations in the kernel to make ip -6 rule working:

CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y

2. Configure a prefix for the Thread network FD00:XXXX:XXXX:XXXX::/64, where XXXX:XXXX:XXXX is the mac address of the main interface of our device. (unique per device, this is an indentifier)
3. Set the IPv6 FD00:XXXX:XXXX:XXXX::1/64 to wpan0 interface
4. Configure a ip -6 rule rule to make sure the correct IPv6 source is used to communicate with Thread interface
5. Start otbr-agent with double -B option, even if the ethernet/wifi interface is not currently "connected":

#!/bin/sh

THREAD_IF="wpan0"
wifi_ifname=$(description-utils get_wifi_ifname)
eth_ifname=$(description-utils get_eth_ifname)

/usr/sbin/otbr-agent -I "${THREAD_IF}" -B "${wifi_ifname}" -B "${eth_ifname}" "spinel+cpc://cpcd_0?iid=2&iid-list=0"

6. We don't need to stop otbr-agent anymore in case of interfaces 'connection' changes, otbr-agent do it by himself
7. When we start the thread network we configure the thread prefix using ot-ctl

Full startup process:

do_start()
{
    # Configure wpan0 IPV6
    echo "0" > /proc/sys/net/ipv6/conf/wpan0/disable_ipv6
    if [[ $? -ne 0 ]]; then
        echo "FATAL: Error configuring wpan0 ipv6"
        exit 1
    fi
    echo "2" > /proc/sys/net/ipv6/conf/${wifi_ifname}/accept_ra
    echo "2" > /proc/sys/net/ipv6/conf/${eth_ifname}/accept_ra
    echo "1" > /proc/sys/net/ipv4/conf/${wifi_ifname}/ignore_routes_with_linkdown
    echo "1" > /proc/sys/net/ipv4/conf/${eth_ifname}/ignore_routes_with_linkdown
    echo "1" > /proc/sys/net/ipv6/conf/${wifi_ifname}/ignore_routes_with_linkdown
    echo "1" > /proc/sys/net/ipv6/conf/${eth_ifname}/ignore_routes_with_linkdown
    
    # Configure the Thread IPV6 prefix
    PREFIX="fd00:$(echo $(description-utils get_mac_addr) | sed -E 's/://g' | sed -E 's/(..)(..)(..)(..)(..)(..)/\1\2:\3\4:\5\6/')::"
    PREFIX_FULL="${PREFIX}/64"
    IPV6="${PREFIX}1"
    IPV6_FULL="${IPV6}/64"
    
    echo "Thread IPv6 Prefix: ${PREFIX_FULL}"
    echo "Thread IPv6: ${IPV6_FULL}"
    
    # Create a rule (if not already exists) that will be used when we want to transmit packets into the Thread network
    # The thread network is identified by the IPv6 prefix:
    # -> FD00:XXXX:XXXX:XXXX::/64
    # Where XXXX:XXXX:XXXX represent the hub MAC address
    if ! ip -6 rule | grep -q "to ${PREFIX_FULL} table 100"; then
        ip -6 rule add to ${PREFIX_FULL} table 100
    fi
    ip addr add ${IPV6_FULL} dev wpan0
    ip -6 route add default dev wpan0 table 100 src ${IPV6}
    
    execute_ot_ctl "ot-ctl prefix add ${PREFIX_FULL} paros med"
    
    # Enable Thread interface
    execute_ot_ctl "ot-ctl ifconfig up"
    execute_ot_ctl "ot-ctl thread start"
    
    # Register configured prefixes, routes, and services with the Leader.
    execute_ot_ctl "ot-ctl netdata register"    
}

Also some documentation:

• https://datatracker.ietf.org/doc/html/rfc6724
• https://datatracker.ietf.org/doc/html/rfc4862

I have tested different scenarios and it works well:

• Starting without WiFi / Ethernet connected + ping the device
• Starting without WiFi / Ethernet connected and connecting it after + ping the device
• Starting with WiFi / Ethernet connected + ping the device
• Starting with WiFi / Ethernet connected and disconnecting it after + ping the device

In all these scenarios we are now able to ping the devices in any situation.

Now we only have one issue:

• When otbr-agent starts with double backbone interface (WiFi/Ethernet) and these interfaces are "not connected", the SRPServer seems to be stopped or not starting.
• So the matter device is not registering it's name when it enters in the network and we can't discover/communicate with it in local using matter-stack.

EDIT:

• For the SRPServer it seems to be explained here: SRP server is disabled when the OTBR loses WLAN connectivity ot-br-posix#1955
• If I enable the SRPServer manually then it works: ot-ctl srp server enable
• But I don't know if it is safe to do it according to the comments on the linked issue. My usecase is: When ETH/WiFi is disconnected, the communication in local with matter devices should continue to work.

[superwhd]

I think the problem here is that it chose the ethernet address instead of wpan0 address.

I used to think this behavior is wrong but after reading https://www.ietf.org/rfc/rfc3484.html#section-5, I think the behavior is correct regarding the RFC (though may not be desired regarding the use case).

When comparing the addresses:
Rule 1: Prefer same address. ---> Both aren't same as destination. Tie.
Rule 2: Prefer appropriate scope. ---> Both have the same scope. Tie.
Rule 3: Avoid deprecated addresses. ----> Wpan0 address is deprecated so it is eliminated. Ethernet address is chosen.

It seems that the Mesh-Local addresses are not so useful on the host from apps' perspective.
Maybe you can manually add an OMR prefix in the network to ensure the BRs always have a non-deprecated addresss.

cc @bukepo