Hi Raimund,
Am Di., 27. Aug. 2019 um 16:55 Uhr schrieb Raimund Oude Hengel <
[email protected]>:
> […]
>
> 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 <
> [email protected]>:
>
>> 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 <
>> [email protected]>:
>>
>>> […]
>>>
>>> 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
>>> [email protected]
>>> https://lists.riot-os.org/mailman/listinfo/users
>>>
>> _______________________________________________
>> users mailing list
>> [email protected]
>> https://lists.riot-os.org/mailman/listinfo/users
>>
> _______________________________________________
> users mailing list
> [email protected]
> https://lists.riot-os.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/users
