Testing of multiple OTBR in a network

[JNayak]

I am using a setup of two sets of RPi+Atmel Radio. Both the RPi are communicating over the lowpan interface using the atmel radio. RPi1 is connected to an Ethernet connection, RPi2 is connected to the internet via wifi.

OTBR docker solution has been deployed in both setups using the steps in DockerSolution. For the NCP, the emulated NCP option has been used.

RPi1 formed the network via the web-gui and RPi2 has joined this network also over the web-gui. State is that of RPi1-Leader and RPi2-Router.

1. I want perform some operations on both of the nodes to test for things like ping and check for rssi. In the docker solution, I am not seeing any point of control where this can be tried (like wpanctl). Is there any way to set this up? I am looking to test the redundancy of having multiple otbr in the network.
2. I want to check the subnet of each of the rpi otbr. Is there any way that this can be tried?

[Jonathan Hui]

Great to hear you are up and running!

If you start a bash session in your container, you can use standard linux commands like ping6 for testing and evaluating IPv6 communication.

$ docker exec -it <container_name> bash

To check the IPv6 subnet prefix of network interfaces, you can use `ifconfig` or `wpanctl status`.

Hope that helps.

--

Jonathan Hui

--
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 post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/2347e332-a436-4680-af35-a0979a9e26a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vishnu Bemera]

hi Jonathan,

  Can you please shed some light on how to test redundancy and resilience feature for the border router?

  In my set up I have multiple border routers, I would like to know what service is running on which border router.

  For example if DHCPv6 is active on border router 1, how to check whether  it is active  and where the backup instance is running.

  Also how to place a border router on a different subnet.

Thanks in advance.

Vishnu

[Jonathan Hui]

Thread manages redundancy of the IPv6 network itself. For example, if multiple border routers offer default routes for the same on-mesh prefix, Thread devices will route packets via the border router with lowest path cost. You can test failover and redundancy simply by enabling/disabling the Thread interface on a given border router.

However, Thread does not manage redundancy of higher-layer services, such as DHCPv6. In the case of DHCPv6, it's probably better to configure the border routers as DHCPv6 Relay Agents and have a single DHCPv6 Server.

--
Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ab67e441-4f11-49cb-915d-13e27f05180f%40googlegroups.com.

[Vishnu Bemre]

  Thanks for valuable information. Can you please let us know how to enable dhcp relay agent.any instructions are available on the thread portal for the same?

  Also, in multiple border router scenario, only one border router(BR1) has ethernet connectivity. Remaining border routers are joined with the border router (BR1)  External ping from the border router(BR1) works fine but it fails from other border routers. I was expecting this ping to be successful and the ping request will be routed via BR1. But looks like this is not happening. can you let me know on what other configuration changes are needed to make the ping successful from other border routers?

Thanks

Vishnu

[Jonathan Hui]

DHCPv6 Relay Agent configuration is outside the scope of Thread. You could take a look at the dhcp6r linux man page.

Regarding the external ping issue, are you attempting to ping an external IPv4 address (thus requiring NAT64) or an IPv6 address?

--

Jonathan Hui

[JNayak]

Hello Jonathan,

The ping was attempted for an ipv6 address - 64:ff9b::acd9:a46e

--

JNayak

[Jonathan Hui]

I believe this is the same issue that was discussed in this prior thread.

The standard OTBR install configures NAT64 as a border router. We need to make an enhancement that allows routing 64:ff9b::/64 via the Thread interface rather than the NAT64 interface when the WAN links is down.

In the mean time, try the following on the OTBR that does not have the WAN link connected:

1. sudo ip -6 route del 64:ff9b::/96
   
2. sudo ip -6 route add 64:ff9b::/96 dev wpan0
   
3. ping6 64:ff9b::acd9:a46e
   

Hope that helps.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/f331d211-49e5-44da-a7c8-a07e95f73511%40googlegroups.com.

[Vishnu Bemre]

hi Jonathan,

  Thanks. After adding the routing via thread interface as you suggested, the ping works fine.

  When the WAN comes back, does the routing resumes via NAT64 automatically? In this scenario, we noticed that ping is not working.

  Please help.

Thanks

Vishnu

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/CAGwZUDuenqsrpRKXjMz7KL8OK9%3DO%3DnJhBtbghRbp6Xipt0gbjQ%40mail.gmail.com.

[Jonathan Hui]

The behavior you observe is currently expected. Unfortunately, the OpenThread border router NAT64 route table is statically configured. As mentioned in my previous email, we need to make an enhancement that dynamically configures the routes based on the status of the WAN and Thread network interfaces. The use of `ip -6 route` commands demonstrates the mechanics behind this and validates that this is possible.

--

Jonathan Hui

[JNayak]

Hello Jonathan,

I am testing the external ping operations further and I see some behaviour that I had not expected.

1. The leader of the network Node1 is an OTBR having connection to the internet via wifi.
   
2. Node2 is also an OTBR and the role of the node in the network is a router. 
   
3. Internet to the Node2 is disconnected (WiFi turned off/Ethernet is disconnected)
   
4. ip route has been updated to go though wpan0 in Node2
   

After following the above steps, the ping to the external network is not successful. If the Node2 is holding a role of end-device, the external ping via wpan0 is OK.

I have put the diagnostics below.

State: Internet connectivity via ethernet is available, node is part of an OT network as a router. Output of the ip route:

root@ea28f467f9c8:/app/borderrouter# ip -6 route show

64:ff9b::/96 dev nat64 metric 1024 pref medium

fd11:22::/64 dev wpan0 proto kernel metric 256 pref medium

fd11:1111:1122::/64 dev wpan0 proto kernel metric 256 pref medium

fdaa:bb:1::2 dev nat64 proto kernel metric 256 pref medium

fe80::/64 dev eth0 proto kernel metric 256 pref medium

fe80::/64 dev nat64 proto kernel metric 256 pref medium

fe80::/64 dev wpan0 proto kernel metric 256 pref medium

State of the node

root@ea28f467f9c8:/app/borderrouter# wpanctl status

wpan0 => [

"NCP:State" => "associated"

"Daemon:Enabled" => true

"NCP:Version" => "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 15 2018 04:41:59"

"Daemon:Version" => "0.08.00d (/47f3212; Oct 24 2018 08:11:10)"

"Config:NCP:DriverName" => "spinel"

"NCP:HardwareAddress" => [18B4300000000001]

"NCP:Channel" => 15

"Network:NodeType" => "router"

"Network:Name" => "2018Nov21-OT"

"Network:XPANID" => 0x1111111122222222

"Network:PANID" => 0x1234

"IPv6:LinkLocalAddress" => "fe80::a88d:4e0c:27eb:2d09"

"IPv6:MeshLocalAddress" => "fd11:1111:1122:0:fc9e:4d36:e873:28aa"

"IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"

"com.nestlabs.internal:Network:AllowingJoin" => false

]

Ping to external network is OK

root@ea28f467f9c8:/app/borderrouter# ping6 64:ff9b::acd9:a46e

PING 64:ff9b::acd9:a46e (64:ff9b::acd9:a46e): 56 data bytes

64 bytes from sfo03s18-in-f14.1e100.net: icmp_seq=0 ttl=42 time=262.728 ms

64 bytes from sfo03s18-in-f14.1e100.net: icmp_seq=1 ttl=42 time=240.813 ms

64 bytes from sfo03s18-in-f14.1e100.net: icmp_seq=2 ttl=42 time=260.450 ms

^C--- 64:ff9b::acd9:a46e ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 240.813/254.664/262.728/9.838 ms

Internet connectivity via ethernet is disconnected, ip route command to use wpan is executed.

root@ea28f467f9c8:/app/borderrouter# sudo ip -6 route del 64:ff9b::/96 

root@ea28f467f9c8:/app/borderrouter# sudo ip -6 route add 64:ff9b::/96 dev wpan0

root@ea28f467f9c8:/app/borderrouter# 

root@ea28f467f9c8:/app/borderrouter# ip -6 route show

64:ff9b::/96 dev wpan0 metric 1024 pref medium

fd11:22::/64 dev wpan0 proto kernel metric 256 pref medium

fd11:1111:1122::/64 dev wpan0 proto kernel metric 256 pref medium

fdaa:bb:1::2 dev nat64 proto kernel metric 256 pref medium

fe80::/64 dev eth0 proto kernel metric 256 pref medium

fe80::/64 dev nat64 proto kernel metric 256 pref medium

fe80::/64 dev wpan0 proto kernel metric 256 pref medium

State of the node

root@ea28f467f9c8:/app/borderrouter# wpanctl status

wpan0 => [

"NCP:State" => "associated"

"Daemon:Enabled" => true

"NCP:Version" => "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 15 2018 04:41:59"

"Daemon:Version" => "0.08.00d (/47f3212; Oct 24 2018 08:11:10)"

"Config:NCP:DriverName" => "spinel"

"NCP:HardwareAddress" => [18B4300000000001]

"NCP:Channel" => 15

"Network:NodeType" => "router"

"Network:Name" => "2018Nov21-OT"

"Network:XPANID" => 0x1111111122222222

"Network:PANID" => 0x1234

"IPv6:LinkLocalAddress" => "fe80::a88d:4e0c:27eb:2d09"

"IPv6:MeshLocalAddress" => "fd11:1111:1122:0:fc9e:4d36:e873:28aa"

"IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"

"com.nestlabs.internal:Network:AllowingJoin" => false

]

Ping to external is unsuccessful

root@ea28f467f9c8:/app/borderrouter# 

root@ea28f467f9c8:/app/borderrouter# ping6 64:ff9b::acd9:a46e

PING 64:ff9b::acd9:a46e (64:ff9b::acd9:a46e): 56 data bytes

^C--- 64:ff9b::acd9:a46e ping statistics ---

56 packets transmitted, 0 packets received, 100% packet loss

From the web gui, Join operation is selected again. The node state changes to end-device

root@ea28f467f9c8:/app/borderrouter# wpanctl status

wpan0 => [

"NCP:State" => "associated"

"Daemon:Enabled" => true

"NCP:Version" => "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 15 2018 04:41:59"

"Daemon:Version" => "0.08.00d (/47f3212; Oct 24 2018 08:11:10)"

"Config:NCP:DriverName" => "spinel"

"NCP:HardwareAddress" => [18B4300000000001]

"NCP:Channel" => 15

"Network:NodeType" => "end-device"

"Network:Name" => "2018Nov21-OT"

"Network:XPANID" => 0x1111111122222222

"Network:PANID" => 0x1234

"IPv6:MeshLocalAddress" => "fd11:1111:1122:0:bc0c:637a:9e1a:b292"

"IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"

"com.nestlabs.internal:Network:AllowingJoin" => false

]

Ping to external network is OK. But when the node is upgraded to router (after 30sec - 2 min), the ping again stops working

root@ea28f467f9c8:/app/borderrouter# ping6 64:ff9b::acd9:a46e

PING 64:ff9b::acd9:a46e (64:ff9b::acd9:a46e): 56 data bytes

64 bytes from sfo03s18-in-f14.1e100.net: icmp_seq=0 ttl=42 time=285.294 ms

64 bytes from sfo03s18-in-f14.1e100.net: icmp_seq=1 ttl=42 time=271.296 ms

64 bytes from sfo03s18-in-f14.1e100.net: icmp_seq=2 ttl=42 time=305.679 ms

Is there any gap in my understanding. Can you please clarify? 

Many thanks,

JNayak

[Jonathan Hui]

External ping should work properly in both router and end device roles.

To help debug, can you use tcpdump to capture pcap files on both Node1 and Node2 wpan0 interface and attach the pcap files here?

Thanks.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/c80d6522-4e0b-4a1d-bf9c-880cfec3db51%40googlegroups.com.

[JNayak]

Hello Jonathan,

I have captured the pcap files on wpan0 interface on both nodes.

• Node1wpan0-Leader.pcap -> Node1 which is a leader, this is capturing for the whole test
  
• Node2wpan0-router-withoutWifi.pcap -> Node2 which is router, ping has been initiated (unsuccessful)
  
• Node2wpan0-endDevice-withoutWifi.pcpa -> Node2 which is end-device, ping has been initiated. After some time when the end-device is promoted to router, the ping fails. This transition has also been captured in the pcap file.
  

If any other details are needed, please let me know. 

Node1-Leader

wpantund[134]: State change: "offline" -> "associating"

wpantund[134]: State change: "associating" -> "associated"

wpantund[134]: Node type change: "unknown" -> "leader"

wpantund[134]: Adding on-mesh prefix "fd11:22::/64" to NCP

wpantund[134]: Pushing a new SLAAC address fd11:22::58d8:fa3b:9e2f:ee41/64 to NCP

wpantund[134]: Adding address "fd11:22::58d8:fa3b:9e2f:ee41/64" to NCP

wpantund[134]: Pushing a new SLAAC address fd11:22::58d8:fa3b:9e2f:ee41/64 to NCP

wpantund[134]: Adding address "fd11:22::58d8:fa3b:9e2f:ee41/64" to NCP

root@29a6eea0521d:/app/borderrouter# wpanctl status                   

wpan0 => [

"NCP:State" => "associated"

"Daemon:Enabled" => true

"NCP:Version" => "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 21 2018 10:42:42"

"Daemon:Version" => "0.08.00d (/47f3212; Oct 24 2018 08:11:10)"

"Config:NCP:DriverName" => "spinel"

"NCP:HardwareAddress" => [18B4300000000001]

"NCP:Channel" => 15

"Network:NodeType" => "leader"

"Network:Name" => "2018Nov22-OT"

"Network:XPANID" => 0x1111111122222222

"Network:PANID" => 0x1234

"IPv6:MeshLocalAddress" => "fd11:1111:1122:0:3a75:c07e:4bba:f104"

"IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"

"com.nestlabs.internal:Network:AllowingJoin" => false

]

Node2-EndDevice->Router

wpantund[134]: Node type change: "end-device" -> "router"

wpantund[134]: State change: "associated" -> "offline"

wpantund[134]: Resetting interface(s). . .

wpantund[134]: Node type change: "router" -> "unknown"

wpantund[134]: [NCP->]: Frame CRC Mismatch: Calc:0x0B23 != Frame:0x0A31, Garbage on line?

wpantund[134]: NCP => wpandev version: 1.1.1

wpantund[134]: [-NCP-]: NCP was reset (RESET_POWER_ON, 112)

wpantund[134]: State change: "offline" -> "uninitialized"

wpantund[134]: State change: "uninitialized" -> "offline"

wpantund[134]: NCP is running "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 15 2018 10:15:44"

wpantund[134]: Driver is running "0.08.00d (/b161ff3; Nov 12 2018 08:26:58)"

wpantund[134]: Network is not joinable

wpantund[134]: Resetting interface(s). . .

wpantund[134]: Finished initializing NCP

wpantund[134]: State change: "offline" -> "associating"

wpantund[134]: State change: "associating" -> "associated"

wpantund[134]: Node type change: "unknown" -> "end-device"

wpantund[134]: Pushing a new SLAAC address fd11:22::cc0e:3b93:3600:81e1/64 to NCP

wpantund[134]: Adding address "fd11:22::cc0e:3b93:3600:81e1/64" to NCP

wpantund[134]: Adding on-mesh prefix "fd11:22::/64" to NCP

wpantund[134]: Node type change: "end-device" -> "router"

wpan0 => [

"NCP:State" => "associated"

"Daemon:Enabled" => true

"NCP:Version" => "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 15 2018 10:15:44"

"Daemon:Version" => "0.08.00d (/b161ff3; Nov 12 2018 08:26:58)"

"Config:NCP:DriverName" => "spinel"

"NCP:HardwareAddress" => [18B4300000000002]

"NCP:Channel" => 15

"Network:NodeType" => "router"

"Network:Name" => "2018Nov22-OT"

"Network:XPANID" => 0x1111111122222222

"Network:PANID" => 0x1234

"IPv6:MeshLocalAddress" => "fd11:1111:1122:0:b168:b9ca:704a:cb5"

"IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"

"com.nestlabs.internal:Network:AllowingJoin" => false

]

Many Thanks,

JNayak

[Jonathan Hui]

Thanks for providing the pcap files.

When node 2 is a router, the pcap files show that the ICMPv6 Echo Request messages are not being received by leader. This typically occurs when an on-mesh prefix with default route has not been configured properly.

You can check the configuration via wpanctl with the following command: "get Thread:OnMeshPrefixes". Try using that command to view the set of on-mesh prefixes on both the leader and router.

If you do not see an on-mesh prefix with default route, you can try using the wpanctl command: "add-prefix"

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/5bd07e69-6a97-43ce-ab54-66efb7f14f56%40googlegroups.com.

[JNayak]

Hello Jonathan,

I checked the onMeshPrefixes as suggested but the data is present. I have logged the OnMeshPrefixes for both nodes below.

I am still seeing the issue (router not able to ping externally via wpan0).

Node1 - Leader:

root@43f9f3caf712:/app/borderrouter# wpanctl status

wpan0 => [

"NCP:State" => "associated"

"Daemon:Enabled" => true

"NCP:Version" => "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 21 2018 10:42:42"

"Daemon:Version" => "0.08.00d (/47f3212; Oct 24 2018 08:11:10)"

"Config:NCP:DriverName" => "spinel"

"NCP:HardwareAddress" => [18B4300000000001]

"NCP:Channel" => 15

"Network:NodeType" => "leader"

"Network:Name" => "2018November-OT"

"Network:XPANID" => 0x1111111122222222

"Network:PANID" => 0x1234

"IPv6:MeshLocalAddress" => "fd11:1111:1122:0:4f02:4aa9:6699:dc9"

"IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"

"com.nestlabs.internal:Network:AllowingJoin" => false

]

root@43f9f3caf712:/app/borderrouter# wpanctl getprop Thread:RLOC16

Thread:RLOC16 = 0x1400

root@43f9f3caf712:/app/borderrouter# wpanctl getprop Thread:RouterTable

Thread:RouterTable = [

"FA3F42032B8DB916, RLOC16:1400, RouterId:5, NextHop:63, PathCost:0, LQIn:0, LQOut:0, Age:0, LinkEst:no"

"7E09136C7519203E, RLOC16:b000, RouterId:44, NextHop:63, PathCost:0, LQIn:3, LQOut:3, Age:37, LinkEst:yes"

"5624927B03B9D6CA, RLOC16:f800, RouterId:62, NextHop:44, PathCost:14, LQIn:0, LQOut:0, Age:35, LinkEst:no"

]

root@43f9f3caf712:/app/borderrouter# wpanctl getprop Thread:OnMeshPrefixes

Thread:OnMeshPrefixes = [

"fd11:22::              prefix_len:64   origin:user     stable:yes flags:0x33 [on-mesh:1 def-route:1 config:0 dhcp:0 slaac:1 pref:1 prio:med] rloc:0x0000"

"fd11:22::              prefix_len:64   origin:ncp      stable:yes flags:0x33 [on-mesh:1 def-route:1 config:0 dhcp:0 slaac:1 pref:1 prio:med] rloc:0x1400"

"fd11:22::              prefix_len:64   origin:ncp      stable:yes flags:0x33 [on-mesh:1 def-route:1 config:0 dhcp:0 slaac:1 pref:1 prio:med] rloc:0xb000"

]

Node2 - Router:

root@995365d770cf:/app/borderrouter# wpanctl status

wpan0 => [

"NCP:State" => "associated"

"Daemon:Enabled" => true

"NCP:Version" => "OPENTHREAD/20170716-00867-g4081d794-dirty; WPANDEV; Nov 15 2018 10:15:44"

"Daemon:Version" => "0.08.00d (/b161ff3; Nov 12 2018 08:26:58)"

"Config:NCP:DriverName" => "spinel"

"NCP:HardwareAddress" => [18B4300000000002]

"NCP:Channel" => 15

"Network:NodeType" => "router"

"Network:Name" => "2018November-OT"

"Network:XPANID" => 0x1111111122222222

"Network:PANID" => 0x1234

"IPv6:MeshLocalAddress" => "fd11:1111:1122:0:6835:635a:f700:335b"

"IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"

"com.nestlabs.internal:Network:AllowingJoin" => false

]

root@995365d770cf:/app/borderrouter# wpanctl getprop Thread:RLOC16

Thread:RLOC16 = 0xB000

root@995365d770cf:/app/borderrouter# wpanctl getprop Thread:RouterTable

Thread:RouterTable = [

"FA3F42032B8DB916, RLOC16:1400, RouterId:5, NextHop:63, PathCost:0, LQIn:3, LQOut:3, Age:16, LinkEst:yes"

"7E09136C7519203E, RLOC16:b000, RouterId:44, NextHop:63, PathCost:0, LQIn:0, LQOut:0, Age:0, LinkEst:no"

"0000000000000000, RLOC16:f800, RouterId:62, NextHop:5, PathCost:11, LQIn:0, LQOut:0, Age:60, LinkEst:no"

]

root@995365d770cf:/app/borderrouter# wpanctl getprop Thread:OnMeshPrefixes

Thread:OnMeshPrefixes = [

"fd11:22::              prefix_len:64   origin:ncp      stable:yes flags:0x33 [on-mesh:1 def-route:1 config:0 dhcp:0 slaac:1 pref:1 prio:med] rloc:0x1400"

"fd11:22::              prefix_len:64   origin:user     stable:yes flags:0x33 [on-mesh:1 def-route:1 config:0 dhcp:0 slaac:1 pref:1 prio:med] rloc:0x0000"

"fd11:22::              prefix_len:64   origin:ncp      stable:yes flags:0x33 [on-mesh:1 def-route:1 config:0 dhcp:0 slaac:1 pref:1 prio:med] rloc:0xb000"

]

root@995365d770cf:/app/borderrouter# wpanctl getprop Thread:Leader:Address

Thread:Leader:Address = "fd11:1111:1122::ff:fe00:1400"

root@995365d770cf:/app/borderrouter# wpanctl getprop Thread:Leader:RouterID

Thread:Leader:RouterID = 0x05

root@995365d770cf:/app/borderrouter# wpanctl getprop Thread:Parent

Thread:Parent = "FA3F42032B8DB916, RLOC16:1400, Age:40, AveRssi:-36, LastRssi:-46, LQIn:3, LQOut:3"

Many Thanks,

JNayak

[Jonathan Hui]

Thanks for the additional information.

It appears that node 2 is still offering a default route via the on-mesh prefix even when it does not have its Ethernet / Wi-Fi connected. When node 2 is operating as a router, the NCP receives the packet from host, performs a route lookup, sees the default route pointing back to the host, but drops the packet because returning the packet back to host would lead to a routing loop.

Can you try removing the on-mesh route from node 2, but keep the on-mesh route from node 1 to see if that resolves your issue? 

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/a467e5b0-ad1a-4586-8693-1c6c50b6bb4c%40googlegroups.com.

[JNayak]

Hello Jonathan,

Thank you for your support. I removed the default prefix from the node which no longer had the Wi-Fi connection and ensured that the other node had the default prefix.

Once that was in place, the external ping started working over the Node1wpan0 ->Node2wpan0->Node2wlan0.

Many thanks,

JNayak

[Jonathan Hui]

Great to hear it's working and thanks for the confirmation.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/5941aa1f-c971-45f7-932d-80260807b2ee%40googlegroups.com.