For some reason I saw very strange behavior regarding state changes on native. When entering ng_ndp_internal_set_state() the state was always DELAY, independent of what it was called with.

Rebased to current master

Rebased to current master

Rebased to current master.

For some reason I saw very strange behavior regarding state changes on native. When entering ng_ndp_internal_set_state() the state was always DELAY, independent of what it was called with.

Is this fixed, or do you still see this strange behavior?

Is this fixed, or do you still see this strange behavior?

Neighbor is reachable and later stale, so it seems to be:

> ifconfig
ifconfig
Iface  7   HWaddr: ea:29:ba:c8:38:be 
           MTU:1500  
           inet6 addr: ff02::1/128  scope: local [multicast]
           inet6 addr: fe80::e829:baff:fec8:38be/64  scope: local
           inet6 addr: ff02::1:ffc8:38be/128  scope: local [multicast]

> ncache
ncache
IPv6 address                    if  L2 address                state       type
------------------------------------------------------------------------------
fe80::58ff:38ff:fead:9beb        7  5a:ff:38:ad:9b:eb         REACHABLE   -
> ncache
ncache
IPv6 address                    if  L2 address                state       type
------------------------------------------------------------------------------
fe80::58ff:38ff:fead:9beb        7  5a:ff:38:ad:9b:eb         STALE       -

Got some fixes over from #3049 that were supposed to be in here.

Hm, no, only Linux isn't responding to RIOT's neighbor solicitation. Maybe this is because of the tun interface?

Mh… can you maybe inject them with scapy for now? I'll try to figure out, what is wrong.

How could I add the ncache entry manually in RIOT?

ncache add <if> <ip-addr> <ll-addr>

oh… the command can't handle address-less link-layers currently ^^ lemme fix that

Gotta go now. However, in the worst case I'm willing to ACK this even if Linux-interaction over slip is not working for now.

Just thinking about it: isn't it quite pointless to send out neighbor solicitations on an addressless link-layer anyway?

Why, for NUD it is still required.

Well, neighbor solicitations are also used to verify if a neighbor is reachable or not.

Adapted ncache shell command

How do you know if a neighbor is reachable if you cannot address it?

You send a neighbor solicitation (either to the IPv6 address of the node if you already know the host [from previous communiction] or to the solicited-nodes multicast address of the IPv6 address if you don't know it) with the IPv6 address of the node in it's target field. If you get a neighbor advertisement with the solicited flag set and the target address being set to the IPv6 address you tested the reachability for, you know the neighbor is reachable.

Hm, okay, but still the Linux side doesn't seem convinced that answering a neighbor solicitation for a tun interface. What about using a tap interface on the Linux side? Wouldn't this make things easier and remove the need for any exception case on the RIOT side?

a) a TAP interface is an Ethernet interface and SLIP is an other link-layer. So I don't see how you would use a TAP, at least not with some effort in tunslip. Are you sure it is because the TUN interface? (Linux' own [IPv6 incapable] SLIP tool slattach also creates a TUN btw).
b) this is definitely out of scope for this PR (let's discuss this in an issue or something like that).

Ok, we don't have the time right now to debug this problem. The rest seems working (though I'm not happy with the rather big changes to "normal" ND), so let's move on. Please squash.

Squashed

Fixed error in shell and squashed immediately

If I add the Linux host manually to the neighbor cache by calling something like ncache add 5 fe80::1 the ping to fe80::1 is sent with the unspecified address as source address...

Have you set a source address on the interface?

lol - I did, but apparently rebooted afterwards. Now it's working.