-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ncp] add border routing InfraIf recv ICMP6 ND #10755
[ncp] add border routing InfraIf recv ICMP6 ND #10755
Conversation
Size Report of OpenThread
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #10755 +/- ##
==========================================
- Coverage 74.57% 71.65% -2.92%
==========================================
Files 609 607 -2
Lines 84911 89163 +4252
==========================================
+ Hits 63321 63889 +568
- Misses 21590 25274 +3684
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
src/lib/spinel/spinel.h
Outdated
* `6`: The IP6 source address of the received message. | ||
* `d`: The data of the received message. | ||
*/ | ||
SPINEL_PROP_INFRA_IF_RECV_ICMP6_ND = SPINEL_PROP_INFRA_IF__BEGIN + 2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we make this general ICMPv6 packets?
SPINEL_PROP_INFRA_IF_RECV_ICMP6_ND = SPINEL_PROP_INFRA_IF__BEGIN + 2, | |
SPINEL_PROP_INFRA_IF_RECV_ICMP6 = SPINEL_PROP_INFRA_IF__BEGIN + 2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. Because after NCP receives this message, otPlatInfraIfRecvIcmp6Nd
should be called which only handles ND messages.
If we want to support other Icmp6 messages in the future, we will need to add extra parsing and handling code in NCP (check if this is a ND or other ICMP6 messages), which introduces extra dependency and adds the complexity of NCP. Because OT core can already handle these, we should let OT core handle them. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bukepo As discussed, use this property for all ICMP6 messages instead of only for ND messages. Added a field in this property for the ICMP6 message type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds okay to me but I am just curios what are some use-cases of non-ND type ICMPv6 messages from infra-if that may be useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now there is no use case of non-ND type ICMPv6 messages from infra-if. I think we can probably leave the extensibility here for the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@abtink Currently, a dedicated host socket is created for joining any multicast group that a node in Thread network subscribes to(see code). It is a trick to leverage Linux kernel's existing MLDv2 implementation to send and process MLDv2 messages. However, the trick actually causes the host itself to subscribe to those multicast groups while the host itself probably isn't interested in them. As a result, unwanted multicast traffic is delivered to the input chain of the host's IPv6 stack. A more elegant way may be handling the MLDv2 messages by OpenThread itself, which avoids creating that host socket. That would require OT to receive and send MLDv2 messages which are also based on ICMPv6.
f88cd26
to
6ff51db
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks.
One suggestion below about adding #if
guard?
src/lib/spinel/spinel.h
Outdated
* `6`: The IP6 source address of the received message. | ||
* `d`: The data of the received message. | ||
*/ | ||
SPINEL_PROP_INFRA_IF_RECV_ICMP6_ND = SPINEL_PROP_INFRA_IF__BEGIN + 2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds okay to me but I am just curios what are some use-cases of non-ND type ICMPv6 messages from infra-if that may be useful?
8640e2f
to
6fdf90a
Compare
src/ncp/ncp_base_ftd.cpp
Outdated
SuccessOrExit(error = mDecoder.ReadIp6Address(address)); | ||
SuccessOrExit(error = mDecoder.ReadData(icmp6Data, len)); | ||
|
||
if (msgType == SPINEL_IPV6_ICMP_TYPE_ND) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is probably unnecessary, as otPlatInfraIfRecvIcmp6Nd
will check the message type. having it may add extra work to the host.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently this line is unnecessary. But without it, the code seem confusing. As we defined SPINEL_PROP_INFRA_IF_RECV_ICMP6
, it could be potentially non ND messages. If we simply call otPlatInfraIfRecvIcmp6Nd
, the code is kind of weird. If we have other ICMP6 case in the future, we should use a switch here. Thoughts? @bukepo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otPlatInfraIfRecvIcmp6Nd()
needs to check whether the packet is ND anyway. If you check the current code, it doesn't verify whether it's ND before delivering them to this API either. We just trust the kernel will do the right thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense. We can update otPlatInfraIfRecvIcmp6Nd
to otPlatInfraIfRecvIcmp6
when there are other icmp6 messages. I added a comment here to avoid confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otPlatInfraIfRecvIcmp6Nd()
explicitly states that the platform should call it with ND messages:
/**
* The infra interface driver calls this method to notify OpenThread
* that an ICMPv6 Neighbor Discovery message is received.
If a platform implementation doesn't adhere to this, I recommend updating or fixing the platform code.
We can update otPlatInfraIfRecvIcmp6Nd to otPlatInfraIfRecvIcmp6
We cannot and should not rename or change existing APIs to ensure backward compatibility. OT public/platform APIs are our contract with vendors/users. We need a very strong justification for any changes and only allow changes after exploring all other options/solutions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll keep that in mind. We won't and shouldn't change otPlatInfraIfRecvIcmp6Nd
for this PR or in the future. I didn't think it clearly enough earlier.
6fdf90a
to
2596ec6
Compare
2596ec6
to
15862a2
Compare
15862a2
to
2610928
Compare
2610928
to
953bfb9
Compare
953bfb9
to
76c6f17
Compare
This PR implements receiving InfraIf Icmp6 Nd messages on NCP.
This is to support border routing for NCP case. See this openthread/ot-br-posix#2398 (comment) for the whole picture of this series of changes.
In this PR, a new spinel property
SPINEL_PROP_INFRA_IF_RECV_ICMP6_ND
is added for the host to pass the ICMP6 ND messages to the NCP.