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
The dependent libraries used by RobotRemoteServer will work with IPv6, but this requires specific documentation and a small code modification (see Issue #60).
The text was updated successfully, but these errors were encountered:
fwiw, at least on Linux, IPv6 is a superset of IPv4. So that, using the example directory a RobotRemoteServer listening on "::" will work with tests.robot with {$ADDRESS} set to ::1, 127.0.0.1, and .
Even specific IPv4 addresses can be used with RobotRemoteServer on IPv6. However, they do require the correct IPv6 subnet. Thus "192.168.1.1" becomes "::ffff:192.168.1.1". Even "::ffff:0.0.0.0" listens on all IPv4 addresses!
I'm happy to create a PR to support IPv6, but I'm not clear on the best approach:
1- document the approach to changing the TCPServer address_family before importing RobotRemoteServer: non-breaking change, but quite a barrier to IPv6 adoption
2- change the universal address from 0.0.0.0 to :: and use IPv6 - this is a breaking change and would invalidate existing use of RobotRemoteServer. IPv4 addresses would need to be prepended with ::ffff:, 0.0.0.0 could, alternatively, be replaced with ::
3- create a new, extra, class for IPv6 - untested approach
4- munge IPv4 addresses to IPv6 versions within RobotRemoteServer - smells wrong, as it's unnecessarily complicated.
The dependent libraries used by RobotRemoteServer will work with IPv6, but this requires specific documentation and a small code modification (see Issue #60).
The text was updated successfully, but these errors were encountered: