Bug 187561

Comment 1 Edwin Groothuis 2014-03-14 01:20:13 UTC

Responsible Changed
From-To: freebsd-ports-bugs->lev

Over to maintainer (via the GNATS Auto Assign Tool)

Comment 2 Lev A. Serebryakov 2014-03-14 07:48:27 UTC

Responsible Changed
From-To: lev->apache


As submitter indnicate, it is generic www/serf problem, not subversion-specific one.

Hi Lawrence,

there was a PR about an IPv6 issue on upstream and a fix is included since serf-1.3.3.
http://code.google.com/p/serf/issues/detail?id=129

That's the changed part in serf/outgoing.c
http://code.google.com/p/serf/source/diff?spec=svn2187&r=2187&format=side&path=/trunk/outgoing.c

I haven't seen and cannot confirm the issue here, even with an IPv6 address on any of the interfaces on my test system.
At the moment I have no idea why this happened on your system.

-- 
olli

Looks like the patch is try all the addresses returned for a host.  Instead 
of giving up on the first one because APR prefers ipv6 over ipv4.

I suppose I could rebuild the APR dependency without the IPV6 default option 
as another fix.

My guess is that there's something else that makes it skip trying IPv6 if 
there are no interfaces with IPv6, but the logic doesn't know to ignore lo0 
when looking to see if there are any?

Digging a bit....there's a comment (apr1 source: network_io/unix/sockaddr.c) 
that per RFC "...does not consider loopback addresses when trying to 
determine if IPv4 or IPv6 is configured on a system", so that matches 
allowing IPv6 to remain enabled on loopback.  But, it goes on saying "This is 
a problem if one actually wants to listen on or connect to loopback address 
of a protocol that is not otherwise configured on the system"...so it works 
around that.

With a note that the routine should accept a flag to determine if the work 
around is wanted.

So sounds like APR forces loopback in for determining if IPv6 is enabled or 
not.  Which would explains why my disabling IPv6 on loopback worked.

On 2014-03-16 06:40, olli hauer wrote:
> Hi Lawrence,
> 
> there was a PR about an IPv6 issue on upstream and a fix is included since 
> serf-1.3.3.
> http://code.google.com/p/serf/issues/detail?id=129
> 
> That's the changed part in serf/outgoing.c
> http://code.google.com/p/serf/source/diff?spec=svn2187&r=2187&format=side&path=/trunk/outgoing.c
> 
> I haven't seen and cannot confirm the issue here, even with an IPv6 address
> on any of the interfaces on my test system.
> At the moment I have no idea why this happened on your system.

-- 
   Name: Lawrence "The Dreamer" Chen    Call: W0LKC
  Snail: 1530 College Ave, A5          Email: beastie@tardisi.com
         Manhattan, KS 66502-2768       Blog: http://lawrencechen.net

Comment 5 Ben Woods 2014-10-04 01:21:51 UTC

I am having this same issue on my FreeNAS box, when running subversion in a jail. However, ifconfig lo0 inet6 ifdisabled did not solve it for me. See below.

# svn co https://svn.redports.org/woodsb02
svn: E000065: Unable to connect to a repository at URL 'https://svn.redports.org/woodsb02'
svn: E000065: Error running context: No route to host
# svn --version
svn, version 1.8.10 (r1615264)
   compiled Sep 25 2014, 07:39:40 on amd64-portbld-freebsd9.1

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.7
  - handles 'http' scheme
  - handles 'https' scheme

# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128 tentative
        inet6 fe80::1%lo0 prefixlen 64 tentative scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair2b: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 02:c2:d9:00:0a:0b
        inet 192.168.1.99 netmask 0xffffff00 broadcast 192.168.1.255
        nd6 options=9<PERFORMNUD,IFDISABLED>
        media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
        status: active

At the present time, things are working for me due to two possible reasons.

I had first got things working again, by rebuilding 'devel/apr1' with IPV6 turned off.  As I recall, a number of services failed to start during a reboot due to the lack of '::1'.

The second reason is I later installed ports bind on my home network, with the FILTER_AAAA option enabled.  And, made use of that.   Since I didn't have this problem at work, because this option is used on the DNS servers there.  At work, IPV6 has been outlawed (and actively being blocked) on our network, and other users were impacted by applications (such as chrome) that preferred IPV6 over IPV4.

Though I usually launch 'www/chromium' with the '--disable-ipv6' option ;)

Though someday I might get around to doing IPV6 on my home network...

Comment 7 Olli Hauer 2016-09-17 19:13:56 UTC

I suspect this issue was fixed in apr by BUG #211430 additional the patch was send to the upstream apr developers

- upstream apache PR:
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59914