Replies: 4 comments 4 replies
-
|
@3oris I believe the answer is technically yes. However, as you mentioned, there may be certain platform-specific aspects to consider, such as port or address reuse. The OT core implementation defines a set of platform APIs/callbacks that it uses to send and receive messages (acting as a simple socket):
The platform implementation should then take care of aspects such as multiple sockets listening to the same port within the implementation of the above platform APIs. |
Beta Was this translation helpful? Give feedback.
-
|
In practice, I found that the UDP port 546 conflict is a hurdle for the co-exist deployment. Both the host's network manager ( While For now I have to explicitly disable the DHCPv6 client feature in the host configuration to allow OT's PD client to run correctly. Example ( |
Beta Was this translation helpful? Give feedback.
-
|
Out of curiosity, what's the exact symptom if you don't disable systemd-networkd's DHCPv6 client? I'm wondering if I'm facing the same problem (my host network is managed by networkd). |
Beta Was this translation helpful? Give feedback.
-
Currently, OpenThread's PD Client binds to port 546 using the wildcard address Although the Linux kernel technically supports distributing unicast packets to multiple binders, it uses a scoring function to prioritize them. A specific IP binding always takes precedence over a wildcard binding. Consequently, systemd-networkd outranks OpenThread, causing all traffic to be routed to systemd-networkd. |
Beta Was this translation helpful? Give feedback.
-
|
What about using virtual network interfaces? Not ideal, but it should provide a way to support multiple DHCPv6 Clients. |
Beta Was this translation helpful? Give feedback.
-
@jwhui , |
Beta Was this translation helpful? Give feedback.
-
|
One problem seems to be that systemd-networkd, according to its documentation, always disables the kernel's implementation of the IPv6 RA protocol. In other words, it keep resetting Source: https://manpages.debian.org/trixie/systemd/systemd.network.5.en.html#%5BNETWORK%5D_SECTION_OPTIONS, sub-section "IPv6AcceptRA":
I even see warnings in
I assume that when this message occurs, networkd is resetting the value to Have you found a way around this conflict? |
Beta Was this translation helpful? Give feedback.
-
Even though resetting accept_ra to 0, |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Regarding border router setup
I think it is a common scenario that the host platform runs some sort of DHCP client (dhclient, NetworkManager, systemd-networkd) on the infra IF in order to get the interface configured.
Usually I would think there might be some sort of conflict when two processes bind to the same address and port, but then I see the use of
SO_REUSEADDRandSO_REUSEPORTas well as DUID matching in the DHCP pd clientSo I wonder if this is designed to be run in parallel with a pre-existing DHCP client on the host. Probably the PD client feature of those clients has to be turned off?
I would be very happy if someone could shed some light.
Beta Was this translation helpful? Give feedback.
All reactions