-
Notifications
You must be signed in to change notification settings - Fork 88
Draft: CoAP server to include IPv6 when no address specified #1453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This is just a strawman hotfix to start the work on fixing IPv6 support for the CoAP server. Untested on IPv4-only machines and not considering the `net.ipv6.bindv6only` sysctl parameter (depends on the expectation of the user).
|
While working on the README revision, I noticed that the issue only appeared on my Raspberry Pi with Linux 5.15.32-v7l+, which has neither ULA nor GUA IPv6 addresses, only the link-local ones. It seems that link-local addresses get filtered when no address is specified, while they are included when passing The original issue I encountered was that mDNS responds with only a With With Also coap-client(.exe) completes this time: This seems highly related to #362 |
|
When I added a manual IPv6 address to that RPi, that one gets listed in the TD, but it was still bound to Link-local addresses never get listed -- this should come from a filter in node-wot. It might make sense to suppress those, but if the device is reachable under a link-local address via DNS name, then the DNS name should be listed. To get the correct one highly depends on a proper host configuration, though, especially when mDNS is involved. |
When starting a servient with a
new CoapServer(), it only binds to IPv4 addresses. At least my expectation is that the CoAP server should bind to all addresses of a host when no specific address is given. Hence, I consider this a bug.This is just a strawman hotfix to start the work on fixing IPv6 support for the CoAP server.
When no address is given to NodeJS
dgram, it only binds to the IPv4 wildcard address (0.0.0.0), but not IPv6 even when the host has it enabled. There might be an implicit default for the type being set toudp4.When passing the IPv6 wildcard address
::to sockets, the expectation is that it binds to both IPv6 and IPv4 addresses (i.e., dual-stack). This can be reconfigured at least under Linux with thenet.ipv6.bindv6onlysysctl parameter, but then the hosts expectation is that the default wildcard means only::without0.0.0.0. It might still confuse node-wot users who are not aware ofnet.ipv6.bindv6only.Please investigate and test this further, as I did not test this on IPv4-only machines. It might directly fail there and might need more code to detect IPv6 support on the host before defaulting to
::.Overall, the issue is with
dgram, whose dual-stack capabilities are quite broken by requiring a decision onudp4vsupd6upfront.