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.
|
try { |
|
host = '::' |
|
family = 6 |
|
this._port = binding.udx_napi_socket_bind(this._handle, port, host, family) |
|
} catch { |
|
host = '0.0.0.0' |
|
family = 4 |
|
this._port = binding.udx_napi_socket_bind(this._handle, port, host, family) |
|
} |
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