BorderRouter: Global IPV6 address lost in ncache after UDP message sent

Hi, I'm using two SAMR21, one with BR (on A) and the other (on B) with gnrc_networking example. I'm on April release. Switch on A (border router) then switch on B, I'm able to send UDP message from Linux to 2001:db8 address of B. If I try to send lot of data (every 100ms), it works for a while and then B does not receive message anymore. After I see it failed, I stopped the loop sending UDP message, I checked on BR and 2001:db8 address of B was not here anymore. I can ping B with fe80:: address on iface 6 but can't with 2001:db8.

Why or how can a node be removed from ncache? Why the node does not automatically reconnect with BR?

Cheers

Hi, can you check if this is ipv6 address vanishes when ARO (wrongly) indicates DUP caused by outdated ncache at router · Issue #5467 · RIOT-OS/RIOT · GitHub?

Why or how can a node be removed from ncache? Why the node does not

automatically reconnect with BR?

As the implementer of the neighbor discovery I can say this: because the neighbor discovery is sh** ;-). It was written in a haste and has a lot of design flaws. I'm working on a replacement (see RFC: network layer API · Issue #5704 · RIOT-OS/RIOT · GitHub, happy to hear your thoughts ;-)), but sadly I did not find some time to put heavy implementation efforts into this yet (hopefully in autumn though, so we have something for the October release, fingers crossed).

Thanks for reporting and kind regards, Martines

Thanks Martine, The issue you mentioned seems to be different.

Did you see the neighbor discovery implementation of OpenThread? How your new implementation will be able to dicuss with OpenThread implementation?

Cheers,

Hi Baptiste,

Hey,

Hi Baptiste,

(sorry, hit the send button for the previous mail accidentally to early)

Thanks Martine, The issue you mentioned seems to be different.

Okay, could you report that issue to the tracker then please so I don't lose track of it.

Did you see the neighbor discovery implementation of OpenThread? How your new implementation will be able to dicuss with OpenThread implementation?

Is it different from RFC 4861 [1] or RFC 6775? If not, then yes it will be able out of the box. If it is different, a port for that should be simple in that the whole routing/address resolution mechanism will be quite interchangeable with the API proposed in #5704 [3] (but since my know-how about OT is very limited, that implementation might need to come from a different person ;-)).

Regards, Martine

[1] RFC 4861 - Neighbor Discovery for IP version 6 (IPv6) [2] RFC 6775 - Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [3] RFC: network layer API · Issue #5704 · RIOT-OS/RIOT · GitHub

Hi,

is it only me who cannot find it or is there something missing here?

Cheers, Oleg

Okay, sorry, I was to fast with my complaint. :wink:

Oleg, you were looking for that: https://github.com/openthread/openthread

Martine, Kaspar, AFAIK, OpenThread follow RFC standard and they added their part on top of it, but I don't know if it will be fully compatible.

Hi,

Oleg, you were looking for that: GitHub - openthread/openthread: OpenThread released by Google is an open-source implementation of the Thread networking protocol

Martine, Kaspar, AFAIK, OpenThread follow RFC standard and they added their part on top of it, but I don't know if it will be fully compatible.

OpenThread doesn't use IPv6 neighbour discovery, they use a forked MLE protocol which is maybe ~80% of that what IETF MLE is. They use MLE for neighbour discovery, means filling neighbour entries with that. Also I saw that they broadcast a stateful compression CID over MLE. The rest I currently try to detect by using the force, ehm source.

Also you cannot be sure that OpenThread really follow any IETF standard and do they own forks. Please see my question [0].

So OpenThread 6LoWPAN is _maybe_ not IETF 6LoWPAN.

- Alex

[0] Redirecting to Google Groups