Hide Forgot
Description of problem: IPv6 packets do not get handled. Version-Release number of selected component (if applicable): kernel-4.18.5-200.fc28.ppc64le How reproducible: Always Steps to Reproduce: 1. Boot the kernel on Power9 hardware such as a Talos II. 2. Configure an interface on an IPv6 network. 3. Watch it fail to work. The problem appears to be in the neighbor discovery. It may go farther than that, but neighbor discovery fails to work. The packets are received on the network interface but the kernel fails to respond properly. From a Linux server with working IPv6 (it is the one at ::1 to the Power9 at ::2), recorded by tcpdump on the Power9: > 15:53:24.195520 IP6 2603:300b:8c5::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2603:300b:8c5::2, length 32 > 15:53:24.216409 IP6 fe80::67b8:184a:bf54:4638 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88 Here is the Power9 trying to ping -6 google.com: > 15:58:53.670600 IP6 2603:300b:8c5::2 > ff02::1:ff4d:9782: ICMP6, neighbor solicitation, who has fe80::80b2:34ff:fe4d:9782, length 32 > 15:58:53.797026 IP6 fe80::80b2:34ff:fe4d:9782 > ff02::1: ICMP6, router advertisement, length 96 > 15:58:53.973038 IP6 fe80::67b8:184a:bf54:4638 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88 > 15:58:54.352715 IP6 fe80::67b8:184a:bf54:4638 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88 > 15:58:54.537682 IP6 fe80::80b2:34ff:fe4d:9782 > ff02::1: HBH ICMP6, multicast listener query v2 [gaddr ::], length 28 > 15:58:54.684082 IP6 fe80::496e:3111:cc4b:68ca > ff02::1:ff01:75e6: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff01:75e6, length 24 > # ip -6 addr > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000 > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: enP4p1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 > inet6 2603:300b:8c5::2/64 scope global noprefixroute > valid_lft forever preferred_lft forever > inet6 fe80::2e09:4dff:fe00:112/64 scope link noprefixroute > valid_lft forever preferred_lft forever > # ip -6 route > ::1 dev lo proto kernel metric 256 pref medium > 2603:300b:8c5::/64 dev enP4p1s0f0 proto kernel metric 100 pref medium > fe80::80b2:34ff:fe4d:9782 dev enP4p1s0f0 proto static metric 20100 pref medium > fe80::/64 dev enP4p1s0f0 proto kernel metric 100 pref medium > fe80::/64 dev enP4p1s0f0 proto kernel metric 256 pref medium > default via fe80::80b2:34ff:fe4d:9782 dev enP4p1s0f0 proto static metric 100 pref medium
ping -6 works for me. As does ssh and https. I have native routable IPv6 on my home network provided by my ISP and it works fine on 4.18.x $ ping -6 google.com PING google.com(prg03s06-in-x0e.1e100.net (2a00:1450:4014:80d::200e)) 56 data bytes 64 bytes from prg03s06-in-x0e.1e100.net (2a00:1450:4014:80d::200e): icmp_seq=1 ttl=52 time=27.1 ms 64 bytes from prg03s06-in-x0e.1e100.net (2a00:1450:4014:80d::200e): icmp_seq=2 ttl=52 time=27.3 ms 64 bytes from prg03s06-in-x0e.1e100.net (2a00:1450:4014:80d::200e): icmp_seq=3 ttl=52 time=27.7 ms This works across x86/arm/aarch664 for me
I seem to have the same problem, also on Talos P9. I'm running radvd on my router/firewall and while a x86_64 F-28 box got the network prefix after starting the died daemon (and has now valid global ipv6 address), my Talos shows only the default link scope address still.
my Talos runs rawhide nodebug kernel 4.19.0-0.rc3.git0.1.fc30.ppc64le
sounds like an issue with kernel 4.18+ (maybe 4.17+), because my old F-28 ppc64le install with 4.16 kernel was to talk IPv6
and it's not Power9 or Talos specific, I've reproduced it also on Power8, both physical and virtual hw.
And looks specific to ppc64le, F-28 ppc64 with 4.18 kernel works correctly.
So Michal found https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9c4943a107b56696e4872cdffdba6b0c7277c77 as potential culprit and I've found https://lore.kernel.org/patchwork/patch/983905/ (from https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-September/177952.html) as a proposed fix
------- Comment From segher.boessenkool.com 2018-09-18 12:38 EDT------- That fix may work, but it really isn't acceptable. Rotating the word (at any stage of the computation; 16 bit, 32 bit, or 64 bit) by one byte (or any odd number of bytes) will do. I think a patch for that was posted as well? Went in even, maybe?
------- Comment From segher.boessenkool.com 2018-09-18 13:10 EDT------- https://patchwork.ozlabs.org/patch/967868/ It was posted, but didn't go in yet.
------- Comment From hannsj_uhl.com 2018-09-24 11:17 EDT------- (In reply to comment #13) > https://patchwork.ozlabs.org/patch/967868/ > . ... which is upstream accepted in the powerpc tree as git commit https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=fixes&id=85682a7e3b9c664995ad477520f917039afdc330 ("powerpc: fix csum_ipv6_magic() on little endian platforms") ...
You can get a 4.19-rc kernel with the fix applied from https://copr.fedorainfracloud.org/coprs/sharkcz/talos-kernel/ and as I confirmed a moment ago, it helps :-)
kernel-headers-4.18.10-200.fc28 kernel-tools-4.18.10-200.fc28 kernel-4.18.10-200.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0edb45d9db
kernel-4.18.10-300.fc29 kernel-headers-4.18.10-300.fc29 kernel-tools-4.18.10-300.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5453baa4af
kernel-headers-4.18.10-100.fc27 kernel-tools-4.18.10-100.fc27 kernel-4.18.10-100.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0a1284064
kernel-4.18.10-300.fc29, kernel-headers-4.18.10-300.fc29, kernel-tools-4.18.10-300.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5453baa4af
kernel-4.18.10-100.fc27, kernel-headers-4.18.10-100.fc27, kernel-tools-4.18.10-100.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0a1284064
kernel-4.18.10-200.fc28, kernel-headers-4.18.10-200.fc28, kernel-tools-4.18.10-200.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-0edb45d9db
kernel-4.18.10-300.fc29, kernel-headers-4.18.10-300.fc29, kernel-tools-4.18.10-300.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.18.10-100.fc27, kernel-headers-4.18.10-100.fc27, kernel-tools-4.18.10-100.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.18.10-200.fc28, kernel-headers-4.18.10-200.fc28, kernel-tools-4.18.10-200.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.