Open kb2ma opened 6 years ago
Hi @kb2ma, can you specify what your set-up is beyond that? Are you using the gcoap
example? Are you communicating with the host system or with another native
application? If it is the latter: which application?
Wait, as far as I can see: you aren't providing the interface with the link-local local address. This is illegal in IPv6 and it was actually a bug in the old ND, that it was possible (and could possibly lead to problems in a multi-interface scenario with equal link-local addresses in the neighbors, say two different border routers configured as fe80::1
on different radios).
With the new NIB you always have to provide the interface with the link-local address (as you would do it also on e.g. Linux).
Thanks for the quick response, Martine. I am using the gcoap example. The CoAP client is RIOT, and the server is libcoap on my Ubuntu workstation.
I understand what you are saying with specification of the interface. When I specify this in the sock_udp_ep_t.netif member for the destination, the request works without the other additions I mentioned.
So what is the recommended way to specify the interface? For my workstation tools, I would append a "%tapN" to the address. Does RIOT have this parsing yet in a string to address function? Is it time for a PR to this effect?
So what is the recommended way to specify the interface? For my workstation tools, I would append a "%tapN" to the address. Does RIOT have this parsing yet in a string to address function? Is it time for a PR to this effect?
Yes there is already a function for this in RIOT: ipv6_addr_split_iface()
. But the recommended way would be to not use link-local addresses, but to use GUAs or ULAs.
Thanks for the recommendations. I'll try them out. I suggest also updating the README for the gnrc_networking example with these best practices.
I suggest also updating the README for the gnrc_networking example with these best practices.
Could you maybe do that? I'm not really sure were to add this so a potential newcomer would see that immediately.
The gcoap example README needs a similar update as well, so let me do that first. Then I'll see how that translates to gnrc_networking.
@kb2ma can this issue be closed?
We solved the main problem of use of link local addresses. However, we expanded that to an update of the gcoap and gnrc_networking READMEs to recommend (and I assume demonstrate) use of ULA/GUA.
So I guess my answer is a question: How do we keep track of the suggestion to update the gcoap and gnrc_networking READMEs? Should there be some other issue that talks more generally about use of ULA/GUA and addressing in RIOT?
I suggest we close this one and wait until someone is motivated enough to propose and get consensus on a simple, standard way to set up a ULA for development/testing.
I'd like to mention that I'm facing the same issue between a Raspberry PI with 801.15.4 enabled and which is propagating an ULA prefix (fd00:ab:ad:1e::/64
).
> ifconfig
2019-03-27 14:36:23,618 - INFO # ifconfig
2019-03-27 14:36:23,623 - INFO # Iface 7 HWaddr: 6b:82 Channel: 26 Page: 0 NID: 0x23
2019-03-27 14:36:23,628 - INFO # Long HWaddr: 79:65:34:58:ec:de:6b:82
2019-03-27 14:36:23,635 - INFO # TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4
2019-03-27 14:36:23,641 - INFO # AUTOACK ACK_REQ CSMA MTU:1280 HL:255 IPHC
2019-03-27 14:36:23,644 - INFO # Source address length: 8
2019-03-27 14:36:23,647 - INFO # Link type: wireless
2019-03-27 14:36:23,652 - INFO # inet6 addr: fe80::7b65:3458:ecde:6b82 scope: local VAL
2019-03-27 14:36:23,659 - INFO # inet6 addr: fd00:ab:ad:1e:7b65:3458:ecde:6b82 scope: global
2019-03-27 14:36:23,662 - INFO # inet6 group: ff02::1
2019-03-27 14:36:23,663 - INFO #
$ ip addr show lowpan0
4: lowpan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1
link/6lowpan 18:c0:ff:ee:1a:c0:ff:ee brd ff:ff:ff:ff:ff:ff:ff:ff
inet6 fd00:ab:ad:1e::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::1ac0:ffee:1ac0:ffee/64 scope link
valid_lft forever preferred_lft forever
Then, when I try to get a CoAP resource on the board with aiocoap-client, I have the following message and the request hangs:
$ aiocoap-client coap://[fd00:ab:ad:1e:7b65:3458:ecde:6b82]/.well-known/core
WARNING:coap:Received Type.ACK from <UDP6EndpointAddress [fe80::7b65:3458:ecde:6b82%lowpan0]:5683 with local address>, but could not match it to a running exchange.
It works if I use:
$ aiocoap-client coap://[fe80::7b65:3458:ecde:6b82%lowpan0]/.well-known/core
</cli/stats>,</riot/board>
By bisecting, I found that 55adbee48808bda975dd5ee420c605bbddf4c94c is the culprit.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.
I think this is still an issue, right?
Thanks for flagging this, @miri64. Looks like it got staled just before #12192 took effect. I will review.
@miri64, the original issue has been handled. The open question is whether @aabadie's example above has been resolved. It seems like there recently was some adjustment on how address scope is chosen among alternatives.
Thanks for raising this @kb2ma. I was pretty I commented somewhere about this issue but couldn't remember where :)
I have found that a gcoap shell example request fails to send a message on the tap interface. The problem looks to be in the NIB module. I describe the problem below, and then show a workaround that hopefully will help the networking wizards understand what's amiss.
The transcript below shows a gcoap example request to the tap interface fails. I have turned on debug in nib.c.
I can get the request to work with two actions. First, in the shell, explicitly add the tap destination to the nib cache.
> nib neigh add 6 fe80::845e:22ff:fe47:a59f 86:5e:22:47:a5:9f
Second, update
gnrc_ipv6_nib_get_next_hop_l2addr()
to retain the generic_netif_t that it finds. gcoap creates the request with the SOCK_ADDR_ANY_NETIF netif. Just below the 'on_link()' test on l.188 in nib.c, I added this:Now the gcoap request succeeds as shown in the transcript below.