How to choose IPv6 vs. IPv4?

[philregier-at-susedotcom]

When trying to debug some difficulties with container-suseconnect-zypp I've noticed that during podman build (i.e., when invoked with RUN) it seems to use IPv6 and fail, whereas during podman run (i.e., invoked with CMD) it seems to use IPv4 and succeed.

I don't think that the distinction between IPv6 and IPv4 is actually the problem, since when I build with --network=host I still see container-suseconnect-zypp use IPv6, but it actually succeeds; however, it would be nice to be able to explicitly set the IP version to help further document this behavior for another GH issue.

Is there a way to explicitly set IPv6 or IPv4 for troubleshooting?

[Vogtinator]

What's the output of ip a and ip l during a podman build? Apparently it has an IPv6 address assigned such that it thinks that IPv6 is usable but it's not actually usable.

[philregier-at-susedotcom]

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 16:14:30:d8:36:b6 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::1414:30ff:fed8:36b6/64 scope link tentative 
       valid_lft forever preferred_lft forever

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether ea:0b:06:9b:eb:64 brd ff:ff:ff:ff:ff:ff

[Vogtinator]

Ok, with no global inet6 address it shouldn't attempt IPv6 at all, but even then it should fall back to IPv4. An strace might help, but we might need some opinion of a go expert.

What does getent hosts scc.suse.com show?

[philregier-at-susedotcom]

Curiously enough, at CMD time, there is in fact a global inet6 address but then it chooses IPv4. :)

At build time, getent hosts scc.suse.com seems to exit nonzero with no output; with --network=host it resolves several IPv4 addresses. getent ahostsv6 scc.suse.com also fails at build time and succeeds at CMD time.

It was actually the output of strace -fyye trace=file,network /usr/lib/zypp/plugins/services/container-suseconnect-zypp that motivated this particular choice of initial issue filings; I don't mind collecting more straces if that would help, but I'm not sure which choices of traces would be most useful.

[philregier-at-susedotcom]

Actually, since getent hosts scc.suse.com seems to fail even to resolve hostnames via IPv4 at build time (note that ping 8.8.8.8 still works just fine) that might be a better route to explore first. I'll see if I can reproduce that issue on other host and guest OSs and post back.

[Vogtinator]

Maybe /etc/resolv.conf requires IPv6 for some reason?

[e4t]

No, it's quite the opposite, unfortunately. The issues occurs due to all IPv6 nameservers on the container host. I've done a detailed analysis which can be found at: https://bugzilla.suse.com/show_bug.cgi?id=1213138