Hi Thomas, 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. /Joakim 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
