See [1] for a fix. [1] https://github.com/RIOT-OS/RIOT/pull/10627
Am Mo., 17. Dez. 2018 um 12:21 Uhr schrieb Martine Lenders < m...@martine-lenders.eu>: > Hi Thomas, > > Am Mo., 17. Dez. 2018 um 11:57 Uhr schrieb Thomas C. Schmidt < > t.schm...@haw-hamburg.de>: > >> Hi Martine, >> >> On 17/12/2018 11:17, Martine Lenders wrote: >> >> > 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 ;-). >> > >> >> Yes, but forwarding to the default upstream should be a failure in this >> case: The packet would then come back from upstream in a loop. >> > > Yes indeed. Forwarding to the default route is definitely an error. > > >> >> Cheers, >> Thomas >> >> > Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt >> > <t.schm...@haw-hamburg.de <mailto: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 <mailto: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 <mailto: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 <mailto:devel@riot-os.org> >> > >> https://lists.riot-os.org/mailman/listinfo/devel >> > > _______________________________________________ >> > > devel mailing list >> > > devel@riot-os.org <mailto: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 <mailto: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
