Bug 863047 - Zypper reports IPv6 error when an IPv4 error occurs
Summary: Zypper reports IPv6 error when an IPv4 error occurs
Status: VERIFIED DUPLICATE of bug 780179
Alias: None
Product: openSUSE 13.1
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Final
Hardware: x86-64 openSUSE 13.1
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Vítězslav Čížek
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-10 11:27 UTC by Mathematical Orchid
Modified: 2014-06-13 13:19 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathematical Orchid 2014-02-10 11:27:03 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0

I just wasted FOUR HOURS trying to figure out why Zypper is using IPv6 on a network that doesn't have IPv6 configured. It turns out that Zypper ISN'T actually using IPv6 at all; it's just that the error message SAYS it is. If I had known that four hours ago, I could have saved myself a hell of a lot of trouble!


Reproducible: Always

Steps to Reproduce:
1. Disable IPv6 in YaST.
2. Prevent IPv4 from connecting somehow. (E.g., firewall everything.)
3. Do zypper refresh.
Actual Results:  
Zypper sits there for about 5 minutes, and then says - and I quote:

"Failed to connect to 2001:67c:2178:8::13: Network is unreachable"

Which is true - but why is it trying to use IPv6 when that's disabled??

Expected Results:  
The ACTUAL error would be far more accurately described as something like "cannot connect to 195.135.221.134: the operation timed out".

Running strace reveals the following:

...
1179  socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5
1179  connect(5, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:2178:8::13", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
1179  close(5)                          = 0
1179  madvise(0x7ff48750c000, 8368128, MADV_DONTNEED) = 0
1179  _exit(0)                          = ?
1179  +++ exited with 0 +++
1177  <... poll resumed> )              = 0 (Timeout)
1177  socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 5
1177  fcntl(5, F_GETFL)                 = 0x2 (flags O_RDWR)
1177  fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
1177  connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("195.135.221.134")}, 16) = -1 EINPROGRESS (Operation now in progress)
1177  poll([{fd=5, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
1177  poll([{fd=5, events=POLLOUT}], 1, 1000) = 0 (Timeout)
1177  poll([{fd=5, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
1177  poll([{fd=5, events=POLLOUT}], 1, 1000) = 0 (Timeout)
1177  poll([{fd=5, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
1177  poll([{fd=5, events=POLLOUT}], 1, 1000) = 0 (Timeout)
...

As you can see, Zypper is CLEARLY timing out while trying to connect to the IPv4 address. The problem has nothing to do with IPv6 at all - yet the error message says it is.
Comment 1 Michael Andres 2014-02-10 12:25:42 UTC
All connection handling is done by libcurl, and it's also libcurl which returns the error message. 
I'm forwarding it to the curl maintainer, maybe there's a way to improve the error reporting.
Comment 2 David Hodgson 2014-04-15 12:54:28 UTC
Still happening.  With the outage of the download.opensuse servers this morning I'm sure a lot of people (like me) have seen this error message and wasted time trying to find the networking problem.
Comment 3 David Hodgson 2014-04-15 13:02:05 UTC
(In reply to comment #1)
> All connection handling is done by libcurl, and it's also libcurl which returns
> the error message. 
> I'm forwarding it to the curl maintainer, maybe there's a way to improve the
> error reporting.

Can I suggest that, if sysconfig says there's no IPv6, zypper creates a curlrc which says "don't try IPv6" and tells curl to use that.  I assume it does that already for the proxy.
Comment 4 David Hodgson 2014-04-15 13:16:09 UTC
I change priority in error.  Now corrected.
Comment 5 Vítězslav Čížek 2014-06-13 13:19:09 UTC
Same as bnc#780179.

*** This bug has been marked as a duplicate of bug 780179 ***