Currently, the UI client connects on IPv4, but the server listens on IPv6 (hardcoded in listen(port)).
So Cadabra 2 depends on IPv6->IPv4 mapping. On BSDs (at least on FreeBSD) such mapping is disabled by default. The relevant sysctl variable is net.inet6.ip6.v6only which is 1 by default (= no mapping). Linux has such mapping enabled.
The FreeBSD port has always had this problem. It was patched in websocketpp before. Now I moved that patch down into cadabra code:
--- client_server/Server.cc.orig 2018-03-31 19:40:16 UTC
+++ client_server/Server.cc
@@ -466,7 +466,7 @@ void Server::run()
wserver.init_asio();
wserver.set_reuse_addr(true);
- wserver.listen(0);
+ wserver.listen(websocketpp::lib::asio::ip::tcp::v4(), 0); // makes up for a failed assumption that IPv6 is mapped into IPv4: (see net.inet6.ip6.v6only=0)
wserver.start_accept();
websocketpp::lib::asio::error_code ec;
auto p = wserver.get_local_endpoint(ec);
I would like to suggest to have a cmake variable USE_IP_PROTOCOL with valid values 4 or 6. Build should use the supplied protocol for both connect and listen, so that there will be no such discrepancy.
(I believe I opened similar issue before, but there was no resolution. There was also no resolution in websocketpp bug. Now I am suggesting a path for a real solution.)
Currently, the UI client connects on IPv4, but the server listens on IPv6 (hardcoded in listen(port)).
So Cadabra 2 depends on IPv6->IPv4 mapping. On BSDs (at least on FreeBSD) such mapping is disabled by default. The relevant sysctl variable is
net.inet6.ip6.v6only
which is1
by default (= no mapping). Linux has such mapping enabled.The FreeBSD port has always had this problem. It was patched in
websocketpp
before. Now I moved that patch down into cadabra code:I would like to suggest to have a cmake variable USE_IP_PROTOCOL with valid values 4 or 6. Build should use the supplied protocol for both connect and listen, so that there will be no such discrepancy.
(I believe I opened similar issue before, but there was no resolution. There was also no resolution in
websocketpp
bug. Now I am suggesting a path for a real solution.)