Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm setting up a box with OpenSUSE 13.1. For reasons beyond my comprehension, Zypper utterly insists on using IPv6 addresses and refuses to use IPv4. Which is a problem, since IPv6 doesn't work on our LAN.

I've tried disabling IPv6 multiple ways:

  • I told YaST to disable IPv6.
  • I tried poking and prodding /etc/modprobe.
  • I tried setting ipv6.disable=1 as a kernel boot parameter.

None of these things had the slightest effect; Zypper still refuses to use real IP addresses and keeps hopelessly trying to use IPv6.

Note that I can ping the download server just fine; the ping command looks up the IPv4 address of the server, and has no problem pinging it. And yet, Zypper still insists on using IPv6, and then giving up because the destination is unreachable. (Which is it - via IPv6.)

I am having the exact problem described in this question. (Even the failing IPv6 address is identical.) That question addresses an older release of OpenSUSE, and the accepted answer just says to disable IPv6, which I already tried.

I have now wasted multiple hours of my life trying to perform the trivial task of installing a few software packages. Does anybody know how I can completely destroy IPv6 and get networking to work again?

share|improve this question
    
Do you have any ipv6 address? localhost? What version of zipper you are using? According to this but report there should be no issue anymore. –  Braiam Feb 7 at 17:57
    
@Braiam Default Zypper version for OpenSUSE. (Indeed, I can't update it!) Zypper version = 1.9.3. ip addr reports an IPv4 address but no IPv6 address. –  MathematicalOrchid Feb 7 at 18:00

2 Answers 2

up vote 1 down vote accepted

I'd comment on this, but I don't have enough points (yet), so, instead, I'll "answer" it: it seems like you've done the right things to zap IPv6 from a kernel perspective, but I might also -- assuming you don't care about IPv6 -- delete any IPv6 entries in /etc/hosts. If that still doesn't do the trick (and this is reaching back), I had a problem with Amanda backup once that was very similar to your issue, and was only able to fix it by installing xinetd instead of inetutils-inetd (note that I have no idea what S.u.S.E. installs by default). Lastly (and as a desperation measure) I might suggest using "strace" with something like: strace -s 1024 -f -o /tmp/zypper.log /path/to/zypperexecutable and then go through the log file looking for that IPv6 address, and seeing if there's anything informative that might be helpful. (FYI, "strace" can generate a HUGE file, so you probably want to abort zypper as soon as it fails.)

share|improve this answer

Following the suggestion by user995746, I tried running strace. Here is what it has to say:

...
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)
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)
1177  poll([{fd=5, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
1177  poll([{fd=5, events=POLLOUT}], 1, 1000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
1177  --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
...

It appears, then, that even though the error message from Zypper quite clearly says "Failed to connect to 2001:67c:2178:8::13: Network is unreachable", the program is actually seeing that IPv6 is unreachable, and falling back to IPv4. The question remains why it can't connect via IPv4 - this is probably some sort of firewall issue with our LAN.

In summary, it appears that IPv6 isn't the problem at all, it's just that the error message from Zypper is highly misleading.

share|improve this answer
    
I filed a bug against Zypper, and they said it's all Curl's fault and escalated it to them. So who knows, maybe this will get fixed someday? –  MathematicalOrchid Feb 17 at 11:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.