You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2010/02/02 12:35:48 UTC
RE: svn commit: r905595 - /subversion/trunk/subversion/svnserve/main.c
> -----Original Message-----
> From: stsp@apache.org [mailto:stsp@apache.org]
> Sent: dinsdag 2 februari 2010 13:03
> To: commits@subversion.apache.org
> Subject: svn commit: r905595 -
> /subversion/trunk/subversion/svnserve/main.c
>
> Author: stsp
> Date: Tue Feb 2 12:02:40 2010
> New Revision: 905595
>
> URL: http://svn.apache.org/viewvc?rev=905595&view=rev
> Log:
> Make svnserve in deamon mode prefer IPv4 addresses when resolving
> the listen hostname, and add a switch to make it prefer IPv6 instead.
>
> This avoids the typical "I just started svnserve and it refuses all
> connections" problem, which is caused by svnserve defaulting to an
> IPv6 wildcard socket on a server which is on an IPv4-only network.
>
> Reported by: nucc1
> (via IRC in #svn, but it's been reported countless times before)
>
> * subversion/svnserve/main.c
> (svnserve__options): Add a --prefer-ipv6 option (short form -6).
> In the help text, document that listening on IPv4 and IPv6 addresses
> at the same time is not supported in daemon mode, and suggest
> workarounds.
> (main): If APR was compiled with IPv6 support, prefer IPv4 addresses
> by default when resolving the listen hostname, unless the -6 option
> was passed. If APR was not compiled with IPv6 support, the -6 option
> is silently ignored.
>
> Modified:
> subversion/trunk/subversion/svnserve/main.c
>
> Modified: subversion/trunk/subversion/svnserve/main.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/svnserve/main.
> c?rev=905595&r1=905594&r2=905595&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/svnserve/main.c (original)
> +++ subversion/trunk/subversion/svnserve/main.c Tue Feb 2 12:02:40 2010
> @@ -179,6 +179,14 @@
> " "
> "[mode: daemon, listen-once]")},
> #endif
> + {"prefer-ipv6", '6', 0,
> + N_("prefer IPv6 when resolving the listen hostname\n"
> + " "
> + "[IPv4 is preferred by default. Using IPv4 and IPv6\n"
> + " "
> + "at the same time is not supported in daemon mode.\n"
> + " "
> + "Use inetd mode or tunnel mode if you need this.]")},
> #ifdef CONNECTION_HAVE_THREAD_OPTION
> /* ### Making the assumption here that WIN32 never has fork and so
> * ### this option never exists when --service exists. */
> @@ -380,6 +388,8 @@
> apr_uint16_t port = SVN_RA_SVN_PORT;
> const char *host = NULL;
> int family = APR_INET;
> + u_int32_t sockaddr_info_flags = 0;
> + svn_boolean_t prefer_v6 = FALSE;
> int mode_opt_count = 0;
> const char *config_filename = NULL;
> const char *pid_filename = NULL;
> @@ -429,6 +439,10 @@
> usage(argv[0], pool);
> switch (opt)
> {
> + case '6':
> + prefer_v6 = TRUE;
> + break;
> +
> case 'h':
> help(pool);
> break;
> @@ -677,10 +691,24 @@
> {
> apr_socket_close(sock);
> family = APR_UNSPEC;
> +
> + if (prefer_v6)
> + {
> + if (host == NULL)
> + host = "::";
> + sockaddr_info_flags = APR_IPV6_ADDR_OK;
> + }
> + else
> + {
> + if (host == NULL)
> + host = "0.0.0.0";
> + sockaddr_info_flags = APR_IPV4_ADDR_OK;
> + }
> }
> #endif
>
> - status = apr_sockaddr_info_get(&sa, host, family, port, 0, pool);
> + status = apr_sockaddr_info_get(&sa, host, family, port,
> + sockaddr_info_flags, pool);
> if (status)
> {
> err = svn_error_wrap_apr(status, _("Can't get address info"));
>
$ svnserve -r /path
listened on IPv6 or on both IPv6 and IPv4 if you compiled APR with IPV6 before this change. (IPv4 if you don't)
After this change it will listen on IPv4 (or break if you don't have IPv4).
These decisions don't belong in our applications, but on the operating or otherwise in a portability library like APR.
Just because more and more users are enabling their systems for IPv6 (as indicated by users seeing this issue) we should not roll back to a IPv4 world.
-0 on this change.
I would prefer a '-4' to explicitly ask for the new behavior of forcing IPv4 on users (maybe also -6 for consistency) and leaving the default via ordering to the operating system and DNS resolvers. (Just as tools like ping, traceroute, etc. do).
We shouldn't try to help users back in the IPv4 only world... We will have to revert this 'default change' within the next 2-3 years anyway...
So we fix a 'bug', by introducing a new bug for the future...
No thanks,
Bert
Re: svn commit: r905595 -
/subversion/trunk/subversion/svnserve/main.c
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 02, 2010 at 01:35:48PM +0100, Bert Huijben wrote:
>
>
> $ svnserve -r /path listened on IPv6 or on both IPv6 and IPv4 if you
> compiled APR with IPV6 before this change. (IPv4 if you don't)
As discussed on IRC, svnserve in daemon mode only supports a single
address family at a time. It does not support both v4 and v6 at the
same time (see #2382).
Unless your OS supports v4-mapped addresses (not all do, or enable them
by default), the default behaviour of svnserve is to listen on a single
v6 wildcard socket. Which makes it not work out of the box for people
who type an IPv4 IP address into their svn URL, or a hostname which
does not resolve to an IPv6 address, or if they don't have IPv6
configured on their network (i.e. the wildcard socket will never
receive packets unless you are on the same ethernet segment as the
server and you type a link-local address -- and nobody does that!).
Most users who run into this problem don't know how to deal with it,
because they aren't aware of the IPv4/IPv6 issues. They may not even
know what IPv6 is, let alone how to configure DNS for their local network.
The case we need to fix is:
user@server$ svnserve -d -r /repos # only listens on :: (v6 wildcard)
# but the user doesn't realise this
user@client$ svn co svn://192.168.1.4/trunk # user gets "connection
# refused" error
The user is using svnserve on a LAN, has a small and cheap v4-only
wireless router box which provides an internet uplink and does DHCP
and DNS for the user (and no, it does not provide local hostnames
in the default configuration, it only resolves DNS hostnames on the
internet). That's quite a common case today, isn't it?
How is the user supposed to deal with this without finding help and
being told to use --listen-address 192.168.1.4?
> After this change it will listen on IPv4 (or break if you don't have IPv4).
If you don't have v4, today, you are advanced enough to check for
a -6 switch. Even if you do have v6 today, you will most likely
still have v4 addresses on your network, and you probably don't
care which protocol svnserve is using (if you do, again, you are
special and advanced, look for the -6 switch).
> These decisions don't belong in our applications, but on the operating
> or otherwise in a portability library like APR.
> -0 on this change.
Are you still -0?
> I would prefer a '-4' to explicitly ask for the new behavior of
> forcing IPv4 on users (maybe also -6 for consistency) and leaving the
> default via ordering to the operating system and DNS resolvers. (Just
> as tools like ping, traceroute, etc. do).
There are ping and ping6, and traceroute and traceroute6 on my system.
One set of tools for v4, the other for v6. It may be different on Windows.
> We shouldn't try to help users back in the IPv4 only world... We will
> have to revert this 'default change' within the next 2-3 years
> anyway...
svnserve now works out of the box for v4-only and for dual v4/v6 network.
These are the common cases. We are getting complaints (or at least,
confused users asking for help) because they don't work out of the box.
Asking and answering questions costs both us and the users time.
For v6-only networks, you need to pass -6. I'll happily sit and wait
patiently until the day the first clueless user pops into the #svn
channel because of a "connection refused" error from svnserve because
the network is v6-only and the user didn't specify -6. First, I will
check to see if my hair is already grey. Then, we can wait a few more
years, and then it'll probably be worth switching the default back.
Stefan