[riot-users] Source address selection

Raimund Oude Hengel raimundoudehengel at googlemail.com
Sun Sep 1 10:02:26 CEST 2019


Hi Martine,

Switching on GNRC_IPV6_NIB_CONF_SLAAC was the winning move. Now my little
network is in perfect working order - as far as I can see.

-The weather-data-server honestly answers requests from Linux host.
-Some other example applications (gcoap, nanocoap) do their work too.
-There is no need to preset source addresses.
-The best: Riot node is pingable from Linux host and vice versa.

The ifconfig output reflects the differences depending on whether GNRC
_IPV6_NIB_CONF_SLAAC is switched on or not.

with CFLAGS += -DGNRC_IPV6_NIB_CONF_SLAAC=1:
inet6 addr: fe80::6717:7427:32d:1036  scope: local  VAL
inet6 addr: fc00::2:6717:7427:32d:1036  scope: global  VAL

without:
inet6 addr: fe80::6717:7427:32d:1036  scope: local  VAL
inet6 addr: fc00::2:6717:7427:32d:1036  scope: global  TNT[3]

I'm new in ipv6-networking, Riot, microcontroller programming. There are
some tiny gaps in knowing what is going on behind the curtain. But now I
feel encouraged to climb the next steps.

Thanks and kind regards from Münster,

Raimund

Am Di., 27. Aug. 2019 um 17:56 Uhr schrieb Martine Lenders <
mail at martine-lenders.eu>:

> Hi Raimund,
>
> Am Di., 27. Aug. 2019 um 16:55 Uhr schrieb Raimund Oude Hengel <
> raimundoudehengel at googlemail.com>:
>
>> […]
>>
>> void setglobaladressflags(void){
>>         /* get interfaces and set their address flags */
>>         gnrc_netif_t *netif = NULL;
>>         while ((netif = gnrc_netif_iter(netif))) {
>>             ipv6_addr_t ipv6_addrs[GNRC_NETIF_IPV6_ADDRS_NUMOF];
>>             int res = gnrc_netapi_get(netif->pid, NETOPT_IPV6_ADDR, 0,
>> ipv6_addrs,
>>                                     sizeof(ipv6_addrs));
>>             if (res < 0) {
>>                 continue;
>>             }
>>             for (unsigned i = 0; i < (unsigned)(res / sizeof(ipv6_addr_t));
>> i++) {
>>                     if (ipv6_addr_is_global (&ipv6_addrs[i])){
>>                         netif->ipv6.addrs_flags[i]=IPV6_ADDR_MCAST_SCP
>> _ORG_LOCAL;
>>
>
> This doesn't seem correct to me. IPV6_ADDR_MCAST_SCP_ORG_LOCAL is a flag
> that is supposed to be *carried* in multicast address [6] [7]. So was the
> "bug" just caused by you using some "random" value?
>
> […]
>>
>> With this addition Riot note was able to send udp messages to linux
>> host. Furthermore there is no need to preset source address, because the
>> RIOT source address selection algorithm finds the global scope address as
>> the best fitting candidate. My posix-socket- server also works. But for
>> curiosity: Pinging Linux host from Riot mode succeeds, pinging Riot node
>> from Linux host fails.
>>
>
> This should be "fixed" with https://github.com/RIOT-OS/RIOT/pull/11970
> (now when the address is invalid the packet is discarded in all cases, even
> when preconfigured).
>
>
>> All in all I think that I found a workaround, not a solution. Are there
>> some high level functions to manipulate address flags? Does the compiler
>> option "-DGNRC_IPV6_NIB_CONF_SLAAC=1" have an influence? (YES)
>>
>> […]
>>
>> I hope, I could answer some of your questions. Thanks a lot for your work.
>>
>
> IPV6_ADDR_MCAST_SCP_ORG_LOCAL and
> GNRC_NETIF_IPV6_ADDRS_FLAGS_STATE_DEPRECATED have the same value, so I am
> not really surprised anymore, that your addresses were marked as invalid,
> yes ;-).
>
> Best regards,
> Martine
>
> [6] https://tools.ietf.org/html/rfc4291#section-2.7
> [7]
> http://api.riot-os.org/group__net__ipv6__addr.html#gab2c7aa747be8ca29c21fcb3619d71ffa
>
>
>> Best regards,
>>
>> Raimund
>>
>>
>>
>> Am Di., 27. Aug. 2019 um 10:55 Uhr schrieb Martine Lenders <
>> mail at martine-lenders.eu>:
>>
>>> Hi Raimund,
>>>
>>> welcome to the RIOT community! Sorry for the late reply.
>>>
>>> For auto-configuration: Have you tried compiling with
>>> `-DGNRC_IPV6_NIB_CONF_SLAAC=1` already [1]? This compile time configuration
>>> is set to 0 for 6LoWPAN/IEEE802.15.4 nodes. 6LoWPAN nodes use a slightly
>>> different way of stateless address auto-configuration [2] from the classic
>>> SLAAC [3] which inclusion is controlled with the configuration flag.
>>> However, Linux does not really support the 6Lo-way of SLAAC so without
>>> classic SLAAC activated the address can't be validated as the ARO is
>>> missing from the NAs [4].
>>>
>>> Am So., 25. Aug. 2019 um 14:32 Uhr schrieb Raimund Oude Hengel <
>>> raimundoudehengel at googlemail.com>:
>>>
>>>> […]
>>>>
>>>> After pulling RIOT master after several weeks without pulling I got a
>>>> new issue. Pinging Riot node from Linux-PC fails. My client-server-set up
>>>> also doesn't work. The Riot-node still gets requests from Linux-PC, but it
>>>> doesn't send answers - if I set ip6-source-address by application code. If
>>>> I don't set source address by application code, the Riot-node answers, but
>>>> with its link-local-address which is not routable.
>>>> Some git diff analysis and ENABLE_DEBUG showed that changes in gnrc_ipv6.c
>>>> caused the different behavior: my preset global scope source address
>>>> (fc00::2:6717:7427:32d:1036) is judged to be invalid.
>>>>
>>>
>>> Mh, if you added it as VALID [5] this definitely sounds like a bug. Were
>>> you able to pin-point the regressing commit with tools like `git bisect` or
>>> `git blame` (mentioning "git diff analysis" makes me think you roughly know
>>> which line causes the behavior)? Knowing this change would be a great help
>>> to determine what is causing this bug.
>>>
>>> Kind regards,
>>> Martine
>>>
>>> [1]
>>> http://api.riot-os.org/group__net__gnrc__ipv6__nib__conf.html#gaa47a6efaa52f16c15e9858994a395ce5
>>> [2] https://tools.ietf.org/html/rfc6775
>>> [3] https://tools.ietf.org/html/rfc4862
>>> [4] https://tools.ietf.org/html/rfc6775#section-5.5.2
>>> [5]
>>> http://api.riot-os.org/group__net__gnrc__netif.html#gaf96707a5e322b5fa8458fba45de01837
>>>
>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users at riot-os.org
>>>> https://lists.riot-os.org/mailman/listinfo/users
>>>>
>>> _______________________________________________
>>> users mailing list
>>> users at riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/users
>>>
>> _______________________________________________
>> users mailing list
>> users at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/users
>>
> _______________________________________________
> users mailing list
> users at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/users/attachments/20190901/813ce6aa/attachment.htm>


More information about the users mailing list