Was trying to downgrade a port, but was getting error connecting to http://svn.freebsd.org Fix: I had tried reinstalling with default port options, same problem. After some Internet searches, there's indication that the serf module will attempt to do only IPv6 if there's an IPv6 address available. But, I have disabled IPv6. I have in /etc/rc.conf: ipv6_network_interfaces="none" ipv6_activate_all_interfaces="NO" ip6addrctl_enable="NO" I had also tried rebuilding devel/apr1 without IPV6. After some more digging around, I noticed that nd6 options for lo0 differed from other interfaces. So, I did: % ifconfig lo0 inet6 ifdisabled Which made svn work. But looking to see why, I found that lo0 is explicitly skipped from getting ifdisabled in /etc/network.subr. So, I'm guessing that's not supposed to be the fix. Another workaround I thought of trying was setting "filter-aaaa-on-v4", but I'm using base bind for my local nameservers and this isn't reason enough to switch to ports bind. How-To-Repeat: % svn log http://svn.freebsd.org/ports/head/deskutils/parcellite svn: E000065: Unable to connect to repository at http://svn.freebsd.org/ports/head/deskutils/parcellite svn: E000065: Error running context: No route to host % svn --version svn, version 1.8.8 (r1568071) compiled Mar 12 2014, 06:36:36 on amd64-portbld-freebsd9.2 Copyright (C) 2013 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. - with Cyrus SASL authentication - 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.4 - handles 'http' scheme - handles 'https' scheme I can connect to the URL using browser fine.
Responsible Changed From-To: freebsd-ports-bugs->lev Over to maintainer (via the GNATS Auto Assign Tool)
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
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...
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