Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-2382

Handle dual-stack IPv4/IPv6 servers in svnserve

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: ---
    • Fix Version/s: 1.8-consider
    • Component/s: libsvn_ra_svn
    • Labels:
      None

      Description

      Patch by Rémi Denis-Courmont (rdenis_at_simphalempin.com).  Fixes svnserve to
      handle the case of a dual-stack server where IPv6 socket() call succeeds, but
      IPv6 isn't really implemented.  Or so I gather... I'm not familiar enough with
      IPv4/IPv6 to know exactly what problem is being solved.
      
      Several developers said they'd like to test the patch, but can't.  Daniel Berlin
      said it looks right to him, and Karl Fogel suggested that if no one can test the
      patch before committing it, a "testing-via-distribution" strategy may be acceptable.
      
      The original patch is archived here:
      http://svn.haxx.se/dev/archive-2005-07/0709.shtml
      

      http://svn.haxx.se/dev/archive-2005-07/0709.shtml

      Original issue reported by mthelen

      1. 1_svn_rasvnaddr.diff
        2 kB
        Joe Orton
      2. 2_svn_rasvnaddr-stsp.diff
        2 kB
        Stefan Sperling

        Issue Links

          Activity

          Hide
          subversion-importer Subversion Importer added a comment -

          Put the archive URL in the issue's URL field.
          

          Original comment by mthelen

          Show
          subversion-importer Subversion Importer added a comment - Put the archive URL in the issue's URL field. Original comment by mthelen
          Hide
          jorton Joe Orton added a comment -

          That patch isn't right, the comments about the APR resolver are inaccurate.  If
          you pass APR_UNSPEC to apr_sockaddr_info_get, it will certainly return both
          AF_INET and AF_INET6 addresses if that's what the underlying system resolver
          returns.
          
          The correct behaviour for any program is to iterate over the list of addresses
          returned by apr_sockaddr_info_get() until a socket()/connect() pair succeeds. 
          This is necessary to correctly use hosts with multiple A records (not uncommon)
          in addition to correctly supporting dual-stack hosts.
          

          Show
          jorton Joe Orton added a comment - That patch isn't right, the comments about the APR resolver are inaccurate. If you pass APR_UNSPEC to apr_sockaddr_info_get, it will certainly return both AF_INET and AF_INET6 addresses if that's what the underlying system resolver returns. The correct behaviour for any program is to iterate over the list of addresses returned by apr_sockaddr_info_get() until a socket()/connect() pair succeeds. This is necessary to correctly use hosts with multiple A records (not uncommon) in addition to correctly supporting dual-stack hosts.
          Hide
          jorton Joe Orton added a comment -

          Attachment 1_svn_rasvnaddr.diff has been added with description: suggested fix

          Show
          jorton Joe Orton added a comment - Attachment 1_svn_rasvnaddr.diff has been added with description: suggested fix
          Hide
          jorton Joe Orton added a comment -

          Created an attachment (id=500)
          suggested fix
          
          

          Show
          jorton Joe Orton added a comment - Created an attachment (id=500) suggested fix
          Hide
          jorton Joe Orton added a comment -

          There are actually two separate issues here: making the client work correctly,
          and making the server work correctly.  
          
          The patch above makes the client work correctly, which should fix many issues.
          
          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 etc etc
          
          (i.e. it needs to reimplement a whole bunch of the logic from httpd)
          

          Show
          jorton Joe Orton added a comment - There are actually two separate issues here: making the client work correctly, and making the server work correctly. The patch above makes the client work correctly, which should fix many issues. 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 etc etc (i.e. it needs to reimplement a whole bunch of the logic from httpd)
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          Remove [PATCH] summary prefix, since the type already is PATCH.
          

          Show
          ehuelsmann Erik Huelsmann added a comment - Remove [PATCH] summary prefix, since the type already is PATCH.
          Hide
          maxb Max Bowsher added a comment -

          Bulk reassign all 42 currently open, non-2.0, PATCH issues to target milestone
          "1.5-consider".
          

          Show
          maxb Max Bowsher added a comment - Bulk reassign all 42 currently open, non-2.0, PATCH issues to target milestone "1.5-consider".
          Hide
          stsp Stefan Sperling added a comment -

          The client-side issue popped up again in
          http://svn.haxx.se/dev/archive-2008-03/0585.shtml
          
          I've updated Joe Orten's patch (attachment id 500) to apply to current trunk:
          http://svn.haxx.se/dev/archive-2008-03/0605.shtml
          It seems to work fine: http://svn.haxx.se/dev/archive-2008-03/0619.shtml
          
          Now I'm waiting for someone to commit it (or allow me to commit it).
          
          I've no idea about the state of the server-side issues Joe mentioned.
          I think we should keep this issue open until someone has had the time
          to investigate svnserve's IPv6 behaviour more closely.
          

          Show
          stsp Stefan Sperling added a comment - The client-side issue popped up again in http://svn.haxx.se/dev/archive-2008-03/0585.shtml I've updated Joe Orten's patch (attachment id 500) to apply to current trunk: http://svn.haxx.se/dev/archive-2008-03/0605.shtml It seems to work fine: http://svn.haxx.se/dev/archive-2008-03/0619.shtml Now I'm waiting for someone to commit it (or allow me to commit it). I've no idea about the state of the server-side issues Joe mentioned. I think we should keep this issue open until someone has had the time to investigate svnserve's IPv6 behaviour more closely.
          Hide
          stsp Stefan Sperling added a comment -

          Created an attachment (id=858)
          Joe Orten's patch (attachment id 500), updated to apply to current trunk.
          
          

          Show
          stsp Stefan Sperling added a comment - Created an attachment (id=858) Joe Orten's patch (attachment id 500), updated to apply to current trunk.
          Hide
          stsp Stefan Sperling added a comment -

          Attachment 2_svn_rasvnaddr-stsp.diff has been added with description: Joe Orten's patch (attachment id 500), updated to apply to current trunk.

          Show
          stsp Stefan Sperling added a comment - Attachment 2_svn_rasvnaddr-stsp.diff has been added with description: Joe Orten's patch (attachment id 500), updated to apply to current trunk.
          Hide
          stsp Stefan Sperling added a comment -

          Client-side fix (attachment id 858) committed in r30004
          and nominated for backport to 1.5.x.
          
          

          Show
          stsp Stefan Sperling added a comment - Client-side fix (attachment id 858) committed in r30004 and nominated for backport to 1.5.x.
          Hide
          kfogel Karl Fogel added a comment -

          *** Issue 3132 has been marked as a duplicate of this issue. ***
          

          Show
          kfogel Karl Fogel added a comment - *** Issue 3132 has been marked as a duplicate of this issue. ***
          Hide
          stsp Stefan Sperling added a comment -

          See here for a user comment illustrating how badly svnserve currently
          behaves on IPv6-enabled hosts:
          http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=76157
          

          Show
          stsp Stefan Sperling added a comment - See here for a user comment illustrating how badly svnserve currently behaves on IPv6-enabled hosts: http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=76157
          Hide
          hwright Hyrum Wright added a comment -

          Moving to 1.6-consider as part of the post-1.5 issue sweep.
          

          Show
          hwright Hyrum Wright added a comment - Moving to 1.6-consider as part of the post-1.5 issue sweep.
          Hide
          stsp Stefan Sperling added a comment -

          Assigning to self.
          
          I have started work on the server-side problem on the issue-2382 branch:
          http://svn.collab.net/repos/svn/branches/issue-2382/
          

          Show
          stsp Stefan Sperling added a comment - Assigning to self. I have started work on the server-side problem on the issue-2382 branch: http://svn.collab.net/repos/svn/branches/issue-2382/
          Hide
          hwright Hyrum Wright added a comment -

          Post-1.6 issue sweep.  Since 1.7 is already shaping up to be a large release,
          move to 1.8-consider.
          

          Show
          hwright Hyrum Wright added a comment - Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release, move to 1.8-consider.
          Hide
          stsp Stefan Sperling added a comment -

          I have removed the issue-2382 branch in r37182.
          
          Basically, I don't think making svnserve handle multiple sockets is worth
          the extra complexity. There are two workarounds for proper dual-stack IPv4
          and IPv6 connectivity:
          
          1) Run svnserve out of inetd with the -i flag.
          2) Use apache.
          
          Closing as WONTFIX.
          

          Show
          stsp Stefan Sperling added a comment - I have removed the issue-2382 branch in r37182. Basically, I don't think making svnserve handle multiple sockets is worth the extra complexity. There are two workarounds for proper dual-stack IPv4 and IPv6 connectivity: 1) Run svnserve out of inetd with the -i flag. 2) Use apache. Closing as WONTFIX.
          Hide
          rhuijben Bert Huijben added a comment -

          You can handle this issue by explicitly saying which address family 
          you would like to listen on on operating systems that don't default
          to listening on both IPv4 and IPv6 (like Windows).
          
          You can do this by adding:
          
          --listen-host 0.0.0.0
          to the svnserve command to listen on all interfaces via the IPv4 addresses
          
          or
          --listen-host ::
          to the svnserve command to listen on all interfaces via the IPv6 addresses
          
          (Most users would need the first version to reproduce the behavior of old IPv4 
          only servers)
          

          Show
          rhuijben Bert Huijben added a comment - You can handle this issue by explicitly saying which address family you would like to listen on on operating systems that don't default to listening on both IPv4 and IPv6 (like Windows). You can do this by adding: --listen-host 0.0.0.0 to the svnserve command to listen on all interfaces via the IPv4 addresses or --listen-host :: to the svnserve command to listen on all interfaces via the IPv6 addresses (Most users would need the first version to reproduce the behavior of old IPv4 only servers)
          Hide
          stsp Stefan Sperling added a comment -

          Answer to previous comment: That does not get you proper dual-stack support.
          This issue tries to address proper IPv4/IPv6 dual-stack operation.
          The only portable way to do this is to listen on multiple sockets,
          one for each address family.
          
          Of course, (as Bert pointed out to me on IRC), multiple svnserve instances
          can be started, too, one for each address family.
          

          Show
          stsp Stefan Sperling added a comment - Answer to previous comment: That does not get you proper dual-stack support. This issue tries to address proper IPv4/IPv6 dual-stack operation. The only portable way to do this is to listen on multiple sockets, one for each address family. Of course, (as Bert pointed out to me on IRC), multiple svnserve instances can be started, too, one for each address family.
          Hide
          stsp Stefan Sperling added a comment -

          As of r905595, svnserve defaults to listening on an IPv4 socket by default,
          unless the listen hostname resolves to an IPv6 address only, or if instructed to
          prefer IPv6 via a -6 command line option. This helps users who start svnserve
          without specifying --listen-address and then try to reach it via an IPv4 IP
          address, or a hostname which does not resolve to an IPv6 address. And it should
          not harm anyone else.
          
          If we ever add proper dual stack support to svnserve, the default behaviour
          should be changed again to listen to both v4 and v6 by default.
          

          Show
          stsp Stefan Sperling added a comment - As of r905595, svnserve defaults to listening on an IPv4 socket by default, unless the listen hostname resolves to an IPv6 address only, or if instructed to prefer IPv6 via a -6 command line option. This helps users who start svnserve without specifying --listen-address and then try to reach it via an IPv4 IP address, or a hostname which does not resolve to an IPv6 address. And it should not harm anyone else. If we ever add proper dual stack support to svnserve, the default behaviour should be changed again to listen to both v4 and v6 by default.

            People

            • Assignee:
              stsp Stefan Sperling
              Reporter:
              subversion-importer Subversion Importer
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development