Hi, at first glance this seems to be indeed a bug. If the prefix `2001:db8::/64` is configured for one interface, this should be hint enough for the NDP to use that interface to multicast the NS there. I'll investigate that.
However, I have to add that RFC 6775 (which applies for the border router) makes the neighbor discovery very destination-oriented (so typically NS are only send upstream performing address registration with the upstream router). So that might also be a legitimate behavior, as downstream nodes should usually be registered via Address registration with the border router or at least a route should be configured to the downstream node with a routing protocol of your choosing ;-). Best regards, Martine Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt < t.schm...@haw-hamburg.de>: > Hi Joakim, > > On 17/12/2018 09:37, Joakim Nohlgård wrote: > > > Thank you for your answer. OK I think I understand what you mean, but > > is this really the correct behavior? > > It was certainly unexpected to me to have the packets go out the > > default route instead of on the interface with the configured prefix. > > > > I will try to elaborate: > > I have a prefix 2001:db8::/64 configured for the wireless interface. > > When I run ping6 2001:db8::1234 from the shell on the RIOT node, I > > expect the system to first attempt to find 2001:db8::1234 on the > > interface which has been configured for that prefix, instead of > > immediately falling back and taking the default route when the > > destination does not already exist in the NIB neighbor table. > > > > I would expect so, too: This should be the correct routing decision and > default routing is wrong. Sorry, I didn't see that in your previous mail. > I'm not sure such fallback makes sense at all, if a specific, globally > routable prefix is configured. If 2001:db8::1234 is not reachable via > 2001:db8::/64, a 'destination unreachable' should be triggered. > > Cheers, > thomas > > > On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt > > <t.schm...@haw-hamburg.de> wrote: > >> > >> Hi Joakim, > >> > >> it appears that you are experimenting with a special case. > >> > >> Normally, a sending node decides on the outgoing interface based on the > >> destination IP prefix. If you don't have a more specific routing entry, > >> the default IF is correctly chosen in your case. > >> > >> After the interface is selected, the source needs to decide on the > >> Layer2 framing. Most link-layer technologies use an addressing > >> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your > >> case, you mention SLIP. A serial line interface does not use L2 > >> addresses and does not need ND. > >> > >> Best, > >> Thomas > >> > >> On 17/12/2018 08:59, Joakim Nohlgård wrote: > >>> Hi developers, > >>> When using the shell on the gnrc_border_router application trying to > >>> send to an unknown address with its designated prefix, the application > >>> does not send any neighbor solicitations on the wireless network. > >>> When I type ping6 2001:db8::1234 I expected that a neighbor > >>> solicitation query to go out on the interface that has been configured > >>> with the routing destination for 2001:db8::/64, but wireshark shows > >>> that nothing is sent on the wireless, but instead the ICMPv6 packet is > >>> sent immediately over the slip/ethos interface, which is configured as > >>> the default route. > >>> > >>> Is this behavior correct or is this a routing bug? > >>> > >>> Configurations: > >>>> ifconfig > >>> Iface 6 HWaddr: 02:DA:F1:03:BC:48 > >>> MTU:1500 HL:64 RTR > >>> RTR_ADV Source address length: 6 > >>> Link type: wired > >>> inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] > >>> inet6 addr: fe80::2 scope: local VAL > >>> inet6 group: ff02::2 > >>> inet6 group: ff02::1 > >>> inet6 group: ff02::1:ff03:bc48 > >>> inet6 group: ff02::1:ff00:2 > >>> > >>> Iface 7 Channel: 26 Page: 0 NID: 0x23 > >>> Long HWaddr: 23:31:53:29:36:B7:6E:5A > >>> TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA > Retries: 4 > >>> ACK_REQ CSMA MTU:1280 HL:64 RTR > >>> RTR_ADV IPHC > >>> Source address length: 8 > >>> Link type: wireless > >>> inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL > >>> inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global > VAL > >>> inet6 group: ff02::2 > >>> inet6 group: ff02::1 > >>> inet6 group: ff02::1:ffb7:6e5a > >>> routing: > >>>> nib route > >>> 2001:db8::/64 dev #7 > >>> default* via fe80::1 dev #6 > >>> > >>> Best regards, > >>> Joakim > >>> _______________________________________________ > >>> devel mailing list > >>> devel@riot-os.org > >>> https://lists.riot-os.org/mailman/listinfo/devel > >>> > >> > >> -- > >> > >> Prof. Dr. Thomas C. Schmidt > >> ° Hamburg University of Applied Sciences Berliner Tor > 7 ° > >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany ° > >> ° http://inet.haw-hamburg.de/members/schmidt Fon: > +49-40-42875-8452 ° > >> > >> _______________________________________________ > >> devel mailing list > >> devel@riot-os.org > >> https://lists.riot-os.org/mailman/listinfo/devel > > _______________________________________________ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° > > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
