mirror of
https://github.com/espressif/openthread.git
synced 2026-09-07 09:40:12 +00:00
Stefan Agner
5edb9fbb0b
The posix platform installs an IPv4 route for the NAT64 CIDR into the Thread network interface so that translated traffic finds its way back to the translator. The IPv6 side has no equivalent: the NAT64 prefix is published as an external route in the network data, but routes published by the device itself are deliberately not installed in the kernel. As a result the border router host cannot use the NAT64 service it provides itself. Traffic to NAT64-synthesized addresses leaks out the default route, or fails with ENETUNREACH when there is no IPv6 default route. This affects the OpenThread features whose sockets are bound to the unspecified network interface and therefore routed by the host: the DNS client (default `OPENTHREAD_CONFIG_DNS_CLIENT_BIND_UDP_TO_THREAD_NETIF` of 0) and the SNTP client, as well as applications running on the host. It makes the built-in NAT64 diagnostics fail in a way that suggests NAT64 itself is broken: `dns resolve4 <name> <ipv4-server>` times out while `ping` to the same synthesized address succeeds, because the ping sender runs inside the OpenThread stack where network data routing reaches the translator directly (see discussion #9782). Traffic originated by Thread devices is translated in the stack as well and was never affected. Install a route for the translator's NAT64 prefix into the Thread network interface while the translator is active, mirroring the existing NAT64 IPv4 CIDR route handling, and track which routes are installed so that repeated state change notifications and host netif link transitions do not add or delete a route twice. `Nat64::Translator::SetNat64Prefix()` now signals `kEventNat64TranslatorStateChanged` (like `SetIp4Cidr()` does), so a prefix change while the translator is already active is reported to the platform. A new public API `otNat64GetIp6Prefix()` is added to retrieve the IPv6 prefix configured in the NAT64 translator, mirroring `otNat64GetCidr()`. Also fix the guards of `AddIp4Route()`/`DeleteIp4Route()` and of the `isIp4` local in `processTransmit()`, which required `OPENTHREAD_CONFIG_BORDER_ROUTING_ENABLE` while their users only require `OPENTHREAD_CONFIG_NAT64_TRANSLATOR_ENABLE`, breaking the build of a NAT64 translator without border routing.