On Mon, Mar 24, 2008 at 10:53:09AM +0000, Darrell Blake wrote:
> > You might want to check the firewall configuration on the machine you
> > are trying to connect to, and verify that svnserve is really running
> > on the server, and listening on the default port (3690 I believe).
> Hmm. I think I may have found a possible problem. When I run a
> "sockstat" I get the following output for the svn server:
> USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
> redneon svnserve 1336 3 tcp6 *:3690
> It looks like the server is running under IPV6 as it's using the tcp6
> protocol. Maybe it's having trouble because I'm trying to access the
> server from an IPV4 based network...
> I wonder if there's any way to recompile svn to us IPV4...
Subversion relies on APR to handle the networking protocol business,
so recompiling Subversion itself won't help you. You could try recompiling
APR without IPv6 support, but I don't think this is the right approach.
Doing this with the system APR might break other programs on your system,
so if you go down that route you should make sure that only Subversion
links to the IPv4-only APR. You might even want to link Subversion statically
in order to make sure, this way the IPv4-only APR library does not end
up being potentially accessible by other programs.
But have you already tried passing a --listen-host option to svnserve?
What do these commands print with and without passing this option?
netstat -an -f inet | grep 3690
netstat -an -f inet6 | grep 3690
This is what it looks like on an OpenBSD machine I'm running
svnserve on (FreeBSD may differ slightly):
$ netstat -an -f inet | grep 3690
tcp 0 0 220.127.116.11.3690 *.* LISTEN
svnserve is started with:
/usr/local/bin/svnserve --daemon \
--listen-host 18.104.22.168 \
The box in quesion does not use IPv6, however.
Also note that svnserve's behaviour wrt IPv6 is an open isssue.
Quoting Joe Orton in http://subversion.tigris.org/issues/show_bug.cgi?id=2382
Making svnserve itself work correctly is more subtle. It should be
binding and listening on multiple sockets if the sockaddr_info_get call
returns multiple address; it needs to take account of the whether the OS
allows V4-mapped addresses to get sensible defaults; when using multiple
sockets it needs to make them all non-blocking and poll across them, etc
(i.e. it needs to reimplement a whole bunch of the logic from httpd)
AFAIK the above hasn't been done yet.
Hope this helps,
Stefan Sperling <stsp_at_elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Received on 2008-03-24 12:31:10 CET
- application/pgp-signature attachment: stored