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 :-/
Received on 2018-06-06 11:23:43 CEST