Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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 >> > 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 >> > > 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 >> > >>>
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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 > > 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 > > > 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 > > >>>
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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. Cheers, Thomas Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt 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 > 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:
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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 > > 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
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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 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
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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 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
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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
[riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
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
