net: openthread: Mesh Local IPv6 is not in zephyr stack

[ramonhpr]

Hello,
I'm facing with a problem. I have a OpenThread setup where I have a raspberry pi as border router and an device nrf52840 where I'm flashing it with the echo_client and in raspberry I have a TCP echo_server in python.
What is happening is that when the nrf52 sends the packet to border router and when it will send it back an error is being raised.

receive data:  Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum id cursus felis, sit amet suscipit velit. Integer facilisis malesuada porta. Nunc at accumsan mauris. Etiam vehicula, arcu consequat feugiat venenatis, tellus velit gravida ligula,   from: ('fdde:ad00:beef::1', 42479, 0, 0)

As you can see, the IP that nrf52 is sending is the one defined by MY_IPV6_ADDR and not the one that the openthread generate by DHCPv6 in openthread, this IP I would to add a route manually in borderrouter.

net iface

Interface 0x20010e00 (<unknown type>) [0]
=========================================
Link addr : 38:12:85:F7:33:85:DB:82
MTU       : 1280
IPv6 unicast addresses (max 3):
        fdde:ad00:beef::1 manual preferred infinite
IPv6 multicast addresses (max 2):
        ff33:40:fd11:1111:1122::1
        ff32:40:fd11:1111:1122::1
IPv6 prefixes (max 2):
        <none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 40480
IPv6 retransmit timer    : 0

ot cmd ipaddr
fdde:ad00:beef:0:0:0:0:1
fd11:1111:1122:0:0:ff:fe00:8001
fe80:0:0:0:42d:87ff:da3:ba27
fd11:1111:1122:0:28e1:5018:7106:40cb
Done

I think that zephyr should use the Mesh local IP that OpenThread generate so the message can reach it back to the device. I've start to develop a solution for that but I don't think if that is the right approach:
https://github.com/ramonhpr/zephyr/commits/devel_ot_dhcp

[jukkar]

Has this been working before? There was recently config file change in echo-client in this commit a159447 that might affect things. Can you try your setup without this commit?

[ramonhpr]

Yes. This was happening before this commit too.

[rlubos]

Hi,
Indeed it looks that OT unicast adresses are not registered in Zephyr. I've talked to the original author, and he said that it was done on purpose - not all OpenThread's unicast addresses should be used by the application. Still, using ML-EID address actually makes sense for the application, so perhaps it makes sense as well to register unicast addresses in Zephyr, especially that you seem to have an use case for that.

I wanted to clarify a few things though.

1. I can see that you've modified ML prefix for you Thread Network (to fd11:1111:1122), yet statically assigned MY_IPV6_ADDR remained the same. In result you use an address for an unregistered prefix (this is not correct according to Thread specification), which is the most likely reason for your routing problems in BR.
2. Both in the description and the code you mention DHCPv6 while referring to ML-EID address. I guess we're mixing terms here. There is no DHCP in Thread network by default, ML-EID is choosen randomly, and no DHCPv6 is involved here. Still, a Border Router can provide DHCPv6 service, but I don't think it is a case here according to your description (unless I miss something).

I've done some testing with unicast address registration in Zephyr, you can check it here: https://github.com/rlubos/zephyr/commits/ot-register-unicast-adresses-in-zephyr. Let me know if they're useful for you, perhaps they could be PRed.

[ramonhpr]

I could, with your patch, use ML-EID in my server border router and it seems to work fine. And indeed I was mixing this terms, thanks for explaining that.

[rlubos]

Thanks for veryfing, I'll create a PR with the changes then. Can we assume that they fix this issue?