|
Bugzilla – Full Text Bug Listing |
| Summary: | Zypper reports IPv6 error when an IPv4 error occurs | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 13.1 | Reporter: | Mathematical Orchid <MathematicalOrchid> |
| Component: | Basesystem | Assignee: | Vítězslav Čížek <vcizek> |
| Status: | VERIFIED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | admin, vcizek |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 13.1 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
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. 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. (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. I change priority in error. Now corrected. Same as bnc#780179. *** This bug has been marked as a duplicate of bug 780179 *** |
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.