Bug 187561 - devel/subversion: bogus "No route to host" caused by www/serf
Summary: devel/subversion: bogus "No route to host" caused by www/serf
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-apache (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-14 01:20 UTC by Lawrence Chen
Modified: 2016-09-17 19:13 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lawrence Chen 2014-03-14 01:20:01 UTC
	
	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.
Comment 1 Edwin Groothuis freebsd_committer 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 freebsd_committer 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.
Comment 3 Olli Hauer 2014-03-16 11:40:32 UTC
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
Comment 4 Lawrence Chen 2014-03-17 16:24:43 UTC
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 freebsd_committer 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
Comment 6 Lawrence Chen 2014-10-09 14:22:47 UTC
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 freebsd_committer 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