On Wed, Jun 06, 2018 at 10:08:58AM +0200, Johannes van der Vegt wrote: > I do "Telnet \\server 3690", and I get: > Connecting To \\server...Could not open connection to the host, on port > 3690: Connect failed > I haven't used Telnet before, so maybe I'm doing something wrong? > > Running TCPView tool(from SysInternals) shows svnserve.exe with protocol > 'TCP' on port 3690, while other ports (other services) do show 'TCPV6'. > > I installed SVN 1.10.0 client on the other client PC, and this also gets > slow. Reverting to 1.9.7 solves this again (because it goes straight to > IPv4). > I'm puzzled... Why is 1.10.0 showing this behavior?
If svnserve is indeed not listening on an IPv6 socket even though the -6 option was provided, then that is unexpected behaviour. There weren't any changes in svnserve between 1.9 and 1.10 which could explain this, though, and it works as expected in a quick test on my system (OpenBSD 6.3) with both SVN 1.10 and SVN 1.9: $ netstat -an -finet6 | grep 3690 tcp6 0 0 *.3690 *.* LISTEN If you can confirm that you're indeed seeing unexpected behaviour, then this behaviour may depend on which version of APR was linked to svnserve because svnserve is opening sockets via APR. The command 'svn --version -v' should show the APR version under 'linked dependencies'. The APR versions used by the SVN builds I've just tested successfully are, respectively: SVN 1.10: APR 1.5.2 (compiled with 1.5.2) SVN 1.9: APR 1.6.3 (compiled with 1.6.3) > Also: Why does SVNServe not provide an IPv6 service on our server PC? As I mentioned before, svnserve does not support both IPv4 and IPv6 at the same time. See https://issues.apache.org/jira/browse/SVN-2382 As documented there I made an attempt to add dual-stack support almost 10 years ago. There is no reason why it couldn't be made to work but I failed at it back then and gave up on solving this task. Starting one svnserve process per address family is the best workaround and I am surprised that it does not work for you :-/