mDNS packets not forward from wlan0 to wpan0 in OTBR

[Wang Haoran]

Hi developers,

   I'm trying to porting Open Thread Broder Router to a POSIX Linux. What I have done is that the otbr-agent can talk to the RCP, otbr-web available to form the Open Thread network. Then I can have the Open Thread end node join the network which formed by my POSIX Linux. 

    ICMPv6's ping6 packet from the OTBR to the end node also works means the local IPV6 network between OT end node and OTBR established.

   

     Then I setup a WiFi AP on the OTBR, using Android mobile to join the WiFi AP. 

      

      By running the service discover App in Android mobile, it will send the mDNS packet through the wlan0 to OTBR to find the available services. The OTBR should forward the mDNS packet to the wpan0. Then wpan0 will send the packet via OpenThread network to the end device.

      But per my test by tcpdump, the mDNS packet didn't forward to wpan0. I think my network configuration is something wrong.

     Here is my network configuration.

     1. wlan0's dhcp based on dnsmasq:

            interface=wlan0

            dhcp-range=192.168.0.2,192.168.0.20,255.255.255.0,24h

      2. Enable radvd for ipv6 RA:

  interface wlan0 {

     AdvManagedFlag on;

     AdvSendAdvert on;

     MinRtrAdvInterval 30;

     MaxRtrAdvInterval 60;

     prefix fd11:33::1/64 {

        AdvOnLink on;

        AdvAutonomous on;

        AdvRouterAddr on;

     };

     route fd11:22::/64 {

     };

  };

    3.  Allow iptables forwarding:

    iptables -A FORWARD -i wlan0-o wpan0 -j ACCEPT

    iptables -A FORWARD -i wpan0 -o wlan0 -j ACCEPT

    After the Open Thread network established, the wpan0 will be assigned as below:

    wpan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280

        inet6 fe80::d8b9:efaf:4bb1:16d9  prefixlen 64  scopeid 0x20<link>

        inet6 fd2a:4971:4b0f:7db7:0:ff:fe00:fc00  prefixlen 64  scopeid 0x0<global>

        inet6 fd2a:4971:4b0f:7db7:0:ff:fe00:a000  prefixlen 64  scopeid 0x0<global>

        inet6 fd2a:4971:4b0f:7db7:ca55:e9bd:dcaa:351a  prefixlen 64  scopeid 0x0<global>

     And the CHILD node will have IPv6 address as the rloc: 

        FD2A:4971:4B0F:7DB7:0:FF:FE00:A002 

     ping6 can work in the OTBR with the CHILD:

root@host:~# ping6 FD2A:4971:4B0F:7DB7:0:FF:FE00:A002

PING FD2A:4971:4B0F:7DB7:0:FF:FE00:A002 (fd2a:4971:4b0f:7db7:0:ff:fe00:a002): 56 data bytes

64 bytes from fd2a:4971:4b0f:7db7:0:ff:fe00:a002: seq=0 ttl=64 time=52.817 ms

64 bytes from fd2a:4971:4b0f:7db7:0:ff:fe00:a002: seq=1 ttl=64 time=51.245 ms

      I think any of the packets from wlan0 won't be able to forward to the wpan0 in my configuration, hopefully can get some clues.

      Very appreciates for you!

[Kangping Dong]

mDNS works on link-local but Wi-Fi network and Thread network are on different links, I don't think it should work.

Thread doesn't use mDNS to do service discovery because multicast is expensive for low power devices. Instead,

unicast service registration protocol and Advertising Proxy is used for discovering Thread services from multicast-capable

link (e.g. Wi-Fi link).

We strongly recommend following the OpenThread Border Router Codelab to set up the Border Router and try out service discovery.

BTW, we are removing Wi-Fi AP setup from openthread.io because it is incompatible with the Border Router codelab. Please connect

your Raspberry Pi to your existing Wi-Fi AP. You can find instructions here: https://www.raspberrypi.org/documentation/configuration/wireless/.

> I think any of the packets from wlan0 won't be able to forward to the wpan0 in my configuration, hopefully can get some clues.

You can validate this by pinging from your mobile phone (or another Raspberry Pi) to the CHILD.

BRs,

Kangping

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/fdd08151-4ec4-4773-8664-2a6571079d8fn%40googlegroups.com.

[Jonathan Hui]

Thread and OpenThread intentionally do not forward mDNS packets into the Thread mesh.

To support DNS-based service discovery, Thread employs:

1. Service Registration Protocol for DNS-Based Service Discovery
2. Advertising Proxy for DNS-SD Service Registration Protocol

OpenThread implements both of the above. Please refer to the following codelab to learn more:

1. Thread Border Router - Bidirectional IPv6 Connectivity and DNS-Based Service Discovery

--

Jonathan Hui

--

[Wang Haoran]

Hi  Kangping & Jonathan,

     Very appreciate for your reply.

     I need to explain more about my environment. Now I'm using the posix Linux running on RPi4 compatible ARM64 hardware platform, not the Ubuntu. The deployment scripts of the ot-br-posix/scripts not able to run directly and I picked the shell codes from the scripts to run in my posix Linux with the crosscompile for the otbr-agent, ot-ctl and otbr-web. 

    With the DNS related discovery services and packets, I seen that in the Codelab page 6, it introducing an Android app named "Service Browser". It is using "mDNS" to discover the servicces with Open Thread Nodes. In my view, I think that the Android phone is in same WiFi subnetwork with the OTBR, and the "Service Browser" can discover the network service provided by the Open Thread nodes under the Openthread subnetwork of the OTBR. My question is that how does the packet sent by "Service Browser" forward to the open thread nodes by the OTBR?

   Very appreciate for you!

[Jonathan Hui]

The mDNS query is not forwarded into the Thread network. Instead, OTBR serves as an advertising proxy. Thread devices register their services with OTBR using the Service Registration Protocol (SRP). OTBR then responds directly to mDNS queries based on the SRP server's currently registered records.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/1e42c454-a14d-43c6-be64-a73bff6ac705n%40googlegroups.com.

[Wang Haoran]

Thanks, Jonathan. This is important to me.

Here I'd like to get more information about it.

The Service Registration Protocol(SRP) looks enabled in OpenThread 1.2, the OpenThread 1.1 seems have no such support.

Besides using the "Service Discover" and the SRP, is there any other test that I can verify the OTBR's capability by forwarding the packets from the WiFi subnetwork to the Openthread subnetwork? Will the "$ping6 ${IPV6_ADDR_OT_NODE}" from the Android mobile able to test it?

Very appreciate for you!

[Jonathan Hui]

On Mon, Jul 12, 2021 at 6:12 PM Wang Haoran <elven...@nxp.com> wrote:

Thanks, Jonathan. This is important to me.

Here I'd like to get more information about it.

The Service Registration Protocol(SRP) looks enabled in OpenThread 1.2, the OpenThread 1.1 seems have no such support.

While the latest ot-br-posix main branch does enable DNS-based Service Discovery, including SRP and advertising proxy, by default, these features are not currently tied to a Thread Protocol version.

Note that "1.1" and "1.2" typically refer to Thread Protocol versions, and not OpenThread itself.

Besides using the "Service Discover" and the SRP, is there any other test that I can verify the OTBR's capability by forwarding the packets from the WiFi subnetwork to the Openthread subnetwork? Will the "$ping6 ${IPV6_ADDR_OT_NODE}" from the Android mobile able to test it?

Yes, you can use ping to verify reachability if you know the node's IPv6 address. However, if you are using Thread 1.1, you likely do not have OpenThread's border routing feature enabled. The border routing feature implements draft-lemon-stub-networks to automatically provide IPv6 reachability between the Thread and Wi-Fi networks. Without the border routing feature, you will need to manually configure IPv6 prefixes and routes.

--

Jonathan Hui

[Kangping Dong]

I need to explain more about my environment. Now I'm using the posix Linux running on RPi4 compatible ARM64 hardware platform, not the Ubuntu. The deployment scripts of the ot-br-posix/scripts not able to run directly and I picked the shell codes from the scripts to run in my posix Linux with the crosscompile for the otbr-agent, ot-ctl and otbr-web.

Would you like to fire an issue at https://github.com/openthread/ot-br-posix/issues? We are willing to help fix it.

Remember to provide the platform/system information, error outputs and steps to reproduce the failure. Thanks!

BRs,

Kangping

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/1e42c454-a14d-43c6-be64-a73bff6ac705n%40googlegroups.com.

[Wang Haoran]

Hi Google friends,

      Very appreciate for your reply.

      Based on Jonathan's suggestion, I think I need to configure the route manually to make the packet available to forward.

      The test network environment is:

       Android mobile <-- (WiFi) --> OTBR  <-- (OpenThread) --> RPi4

                                            <----- ICMPv6 ping6 -----------------------------                        

      

       The IPv6 address of Android mobile is: fd11:33::44b4:fbff:feb5:88f5

       In the RPi4(The OT end node), I tried to add the route to make it access Android mobile by ping6:

       $sudo ip -6 route add fd11:33::1/64 dev wpan0

        I can see the "$ping6 fd11:33::44b4:fbff:feb5:88f5" is trying to send packet to wpan0. But in the OTBR, I didn't see any packet received.

        Then I turn on the logs of ot-daemon to track something. Found the the route didn't enable inside the ot-daemon. Then I added the route info by below instructions, but still failed to route the packets.

ubuntu@ubuntu:~/project/openthread/openthread/build/posix/src/posix$ sudo ./ot-ctl

> factoryreset

> dataset set active 000300000f35060004001fffe0020811111111222222220708fde693b87bb85a63051000112233445566778899aabbccddeeff030e4f70656e54687265616444656d6f01021234041061e1206d2c2b46e079eb775f41fc72190c0302a0ff0e080000000000000000

Done

> ifconfig up

Done

> thread start

Done

> state

child

Done

>

>

> netdata show

Prefixes:

fd11:22:0:0::/64 paros med d400

Routes:

Services:

Done

> route add fd11:33:0:0::/64 s

Done

> state

child

Done

> netdata register

Done

> state

child

Done

> netdata show

Prefixes:

fd11:22:0:0::/64 paros med d400

Routes:

fd11:33:0:0::/64 s med d400

fd11:33:0:0::/64 s med d401

Services:

Done

> ping fd11:33::44b4:fbff:feb5:88f5

> 1 packets transmitted, 0 packets received. Packet loss = 100.0%.

Done

      Meanwhile, the ot-daemon reported logs like below:

 Jul 14 10:29:30 ubuntu ./ot-daemon[58570]: [INFO]-PLAT----: > ping fd11:33::44b4:fbff:feb5:88f5

Jul 14 10:29:30 ubuntu ./ot-daemon[58570]: [INFO]-ICMP----: Sent echo request: (seq = 1)

Jul 14 10:29:30 ubuntu ./ot-daemon[58570]: [INFO]-PLAT----: processReceive: OK

Jul 14 10:29:30 ubuntu ./ot-daemon[58570]: [WARN]-PLAT----: processTransmit: NoRoute

        Is there anything else I need to config the route?

        Thanks!

[Simon Lin]

Note that `ot-ctl ping` never works when the destination is a WiFi device because OTBR won't forward the ping response (even if it receives successfully) to OpenThread. So, `ot-ctl ping` won't be notified of the Ping Response, and always concludes with timeout. 

You can use wireshark to see if the Ping Response was actually on the WiFi link to OTBR. 

You always need to use Linux command `ping -6` to ping a WiFi device on an OTBR. 

[Wang Haoran]

Hi Google friends,

     Thank you very much for helping in this issue.

     Now I'm using latest ot-br-posix tree with -DOT_THREAD_VERSION=1.1 flag, the ICMPv6 packets are available to travel between OpenThread end device and WiFi end device.

     Thanks!