gnrc_ipv6_nib: Findings from testing new NDP implementation #7713
Comments
smlng
added
Area: network
|
failed assertion using |
It's a little bit unfair to point this out if that was never the goal for NIB (not NDP2, that's just the send and header assembly module now). [edit]Goal of NIB up to #7479 was always to implement just RFCs 4861 and 6775 (and provide the footing for future extensions into other RCFs)[/edit] |
Did you add the prefix using |
|
(but until RFC 4862 isn't implemented properly this isn't important anyway). |
|
Rest I will fix tomorrow :-) |
wasn't meant to diss NDP2 by that, more as a general ToDo what RIOT is missing, sorry if you got that wrong. |
|
Did not got it wrong, just wanted to make sure we are on the same page here ;-) |
miri64
changed the title
|
Just to clarify: the name of the new neighbor discovery implementation is not NDP2! |
Just looked into this: The indefinite part comes from RFC 6775. I'll fix it for classic IPv6. |
Fix RS retransmission issue stated in RIOT-OS#7713
I'm unsure how you mean that. Do you expect a set L-flag to auto-generate an address (that would be wrong, a set A flag does that) or are you pointing out that with an set A flag but an unset L flag, the address is auto-generated, while a set A flag and a set L flag doesn't? |
Also unclear, how you mean that: do you mean there are only 2 RAs send in short intervals and then none afterwards (which would be wrong) or are the only 2 RAs in very short intervals and then longer intervals between them afterwards (which except for the 2 be the right way). |
|
@smlng also, I get 4 (!) RAs in 16s interval differences (which is the specified short interval). Can you maybe provide a dump of the output with the following patch? diff --git a/sys/net/gnrc/network_layer/ipv6/nib/_nib-router.c b/sys/net/gnrc/network_layer/ipv6/nib/_nib-router.c
index a3e4675..dafdd58 100644
--- a/sys/net/gnrc/network_layer/ipv6/nib/_nib-router.c
+++ b/sys/net/gnrc/network_layer/ipv6/nib/_nib-router.c
@@ -69,6 +69,8 @@ void _handle_snd_mc_ra(gnrc_netif2_t *netif)
}
/* netif->ipv6.ra_sent overflowed => this was our last final RA */
if (netif->ipv6.ra_sent != 0) {
+ printf("test %u (next in %u ms)\n", netif->ipv6.ra_sent,
+ next_ra_time);
_evtimer_add(netif, GNRC_IPV6_NIB_SND_MC_RA, &netif->ipv6.snd_mc_ra,
next_ra_time);
} |
exactly, the A flag is set in both cases but an address is only auto generated if L flag is not set, from what I read the L flag should not have any influence on whether or not an IPv6 address is auto generated. |
also right, I see 2 sort RAs (namely at 1.5 and 16.2 seconds, for instance) and the next after roughly 500s and 1000s and so on (every 500s, approx). The standard defines 3 RAs retransmission in short succession when a link gets ready, however that is (and should be) configurable. I think its set to 3 but the comparison is wrong so only 2 are actually send in short interval on start up. |
hmm, maybe I tested with an older version, will retest - but the general behaviour is already right, just the actual count seemed of in my tests. |
|
Can you also reply to #7713 (comment), please? |
yes but it also states: The RECOMMENDED rate of retransmissions is to what I saw was indefinite RS with an 4s interval in my tests, above it reads 10s for the first 3 and slower interval (that is >10s) afterwards. |
Yes for classic NDP it is 4s. I only stated the behavior was taken from 6LoND, not the timings ;-) |
@smlng have you? |
Fix RS retransmission issue stated in RIOT-OS#7713
Fix RS retransmission issue stated in RIOT-OS#7713
|
As I did not see the reported RAs and @bergzand also didn't report anything like this, I close this issue for now. Please reopen if you disagree. |
|
Started (re)testing of #7925 😄 First issues I found were a compile error and a command which wasn't working as expected see #8144. Further, I found the following behaviour I'm unsure if that is correct or expected, here is what I did: I run single instance of
|
|
forgot to clarify: 1 and 2 look fine to me, but 4 seems to be odd |
|
@bergzand you're right, works - I made a mistake: I added the entry manually but for the wrong interface, i.e. 7 instead of 6 -> with 6lo the interface pid is 7, but w/o 6lo (as for ethernet/tap on native) the pid is 6 😦. Interesting side effect: after manually adding a faulty entry and ping6 on the host lladdr there are 2 entries in the nib for the same address and lladdr, but on different interfaces. While the
|
or more correct: you have to delete in a loop to remove all entries, but you cannot select (or know) which will be deleted first - at least if you do not know in which order they were added 😉 |
|
I started to test on boards, first issue/question: with 6lo active RFC6775 applies, which says ND is host-initiated and does not use multicast. So question for latter: why does RIOT still join its sol. mcast address? Here |
|
Can you please summarize your findings again? I'm a bit confused what the issue is still. |
Is this the only remaining issue in this issue (wording chosen intentionally ;-P)? Yes it does make sense to have 2 entries with the same IP address at least (lladdr might also work if they are in distinct networks). An example: A device has two radios and is in direct neighborhood for the border routers of each radio network. The administrators for both border routers are a bit lazy, so for both the link-local address is Regarding the |
|
Not a blocking issue, but important for the long run: All nodes are in range. The 6lh sets a default route to the router from the first received RA. After some research, we came across RFC4191. RAs can basically contain a preference number and according to RFC6775, the preference MUST be set to high for 6lbrs, if this preference option is used. IMO it makes sense to choose the 6lbr directly in a network where severel 6lrs are present in the vicinity. I was able to set the preference of the 6lbr (via radvd) to high, but RIOT is not parsing that at the moment. |
|
@cgundogan can you open a separate issue for that (though I added the functionality in RFC4191 to #3052). However, I don't think RFC4191 alone will fix this issue, but rather that is also an interplay with the issue @smlng pointed out during today's call, that (current) Linux does not behave according to RFC6775 and expects the neighbor to be in the solicited-nodes address of its address. Maybe @alexaring can give a hint on the status of 6Lo-ND in Linux, if he is still up-to-date on that. |
|
@cgundogan did you open the issue I asked for? If not, please do so. Since #7925 is merged now, I'm closing this issue. |
|
@miri64 there is not support right now, except I did some user space implementation for sending 6CO and parsing them (then setup contexts afterwards), just early state and RIOT had already support for this RFC6775 "feature". I am aware of some contiki fork for RFC6775 (which they didn't had upstream yet, don't know the current state) - don't know the name/repository anymore. Sorry. Linux support needs some time do find some "acceptable" architecture of "what doing in kernel and what in user space", which also fits to the current IPv6 architecture. Maybe @Stefan-Schmidt knows something about that... People are more interessted in Thread, but they don't use RFC6775 at all (so far I saw). |
I started testing the new NDP based on #7479, this issue is meant to collect observations, problems and findings observed, so far. List will be extended
General observations
1b36cdf7)ff02::1andff02::2(233237d)IPv6 standard ND
tested between RIOT native (with modified
examples/gnrc_networking) and host system (macOS, or Linux)RIOT as host (ticked means fixed)
radvdfrom Linux host, when PIO L (on-link) flag is set (on) - on current master with ndp1 it works (bb40393)nib prefixand also not innib route, the latter has only the default entry, which is likely sufficient (bb40393)RIOT as router
infinityby default, might be better to have a lower default? (73406c8, when usingnib prefix addfirst to set the prefix with lifetime and thenifconfigto add the address)IPv6 6LoWPAN ND
The text was updated successfully, but these errors were encountered: