You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently investigating an issue with Hyperswarm, where it is unable to establish a connection between two Docker containers running on different machines on different networks and connected to their respective "bridge" interface (note: when one of the two machines uses "--network host" the connection is established, but this workaround is undesirable for several reasons).
The issue seems to be caused by libudx defaulting to binding to an IPv6 socket, which works within the containers but causes incoming packets to be dropped.
This may be due to IPv6 being disabled by default on the Docker daemon.
By forcing the use of IPv4 in the code below, the issue can be resolved.
If IPv6 needs to be the default, i think a flag should be added to the library, allowing the software using it to force IPv4 when running on platforms with this issue.
For others facing a similar problem: this is a workaround to forcefully disable IPv6 on the current version of libudx from the application code without modifying the library
importUDXBindingfrom"udx-native/lib/binding.js";functiondisableIPv6(){const_udx_napi_socket_bind=UDXBinding.udx_napi_socket_bind;UDXBinding.udx_napi_socket_bind=function(...args){if(args[3]==6)throw"IPv6 is disabled"_udx_napi_socket_bind(...args);}}disableIPv6();
I haven't been able to replicate the @hyperswarm/doctor results you posted in Discord, I'm consistently getting a Peer not found error even if only binding to IPv4. However, disabling all the IPv6-only tests in libudx makes everything pass as expected so the default dual-stack bind appears to work 🤔 That is, by binding to all available IPv6 and IPv4 addresses, which is what the "any" address :: will do, IPv4 traffic goes through just fine while IPv6 traffic times out.
I am currently investigating an issue with Hyperswarm, where it is unable to establish a connection between two Docker containers running on different machines on different networks and connected to their respective "bridge" interface (note: when one of the two machines uses "--network host" the connection is established, but this workaround is undesirable for several reasons).
The issue seems to be caused by libudx defaulting to binding to an IPv6 socket, which works within the containers but causes incoming packets to be dropped.
This may be due to IPv6 being disabled by default on the Docker daemon.
By forcing the use of IPv4 in the code below, the issue can be resolved.
If IPv6 needs to be the default, i think a flag should be added to the library, allowing the software using it to force IPv4 when running on platforms with this issue.
libudx/lib/socket.js
Lines 133 to 141 in 9a1760a
The text was updated successfully, but these errors were encountered: