Bug 1178221 - Latest image for openSUSE-Tumbleweed pine64 gets no IPv4 connection
Latest image for openSUSE-Tumbleweed pine64 gets no IPv4 connection
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
aarch64 openSUSE Tumbleweed
: P5 - None : Major (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-10-28 14:44 UTC by Freek de Kruijf
Modified: 2021-04-15 10:43 UTC (History)
4 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 Freek de Kruijf 2020-10-28 14:44:15 UTC
I used openSUSE-Tumbleweed-ARM-JeOS-pine64.aarch64-2020.10.25-Build11.2.raw.xz to build a system for my Banana Pi M64. After starting the system I do have an IPv6 connection, but no IPv4 connection

I arrived at this test because I upgraded that system, which started with 2020.08.15-Build11.11. I configured that system, disabling IPv6. After the upgrade I did not have an IPv4 connection anymore. The interface eth0 was UP, but it did not have/get an IPv4 address.

Probably something is wrong with getting an address via DHCPv4.

I did have the older image and now I have a system with both an IPv4 and IPv6 address. So the hardware is OK.
Comment 1 Reinhard Max 2020-11-04 13:47:58 UTC
This bug got assigned to me probably because I am the maintainer of the dhcp package. But I have no idea how to test and reproduce this in the given scenario of a JeOS image. So, I am passing this on to the JeOS folks for now to clarify what's going on. Feel free to assign it back to me if the dhcp package turns out to be the culprit here.
Comment 2 Fabian Vogt 2020-11-04 13:55:56 UTC
jeos-internal@suse.de is not for openSUSE ARM JeOS. In any case, this sounds like either a kernel, firmware or maybe wicked issue. Currently my guess is the former, so reassigning.

Do you have packet traces?
Which packages changed between the images? You can narrow that down by updating the older image to the latest packages in steps.
Comment 3 Freek de Kruijf 2020-11-04 16:54:43 UTC
(In reply to Fabian Vogt from comment #2)
> jeos-internal@suse.de is not for openSUSE ARM JeOS. In any case, this sounds
> like either a kernel, firmware or maybe wicked issue. Currently my guess is
> the former, so reassigning.
> 
> Do you have packet traces?
> Which packages changed between the images? You can narrow that down by
> updating the older image to the latest packages in steps.

I only did "zypper up kernel-default" and "shutdown -r now" and ended up with an eth0 device in UP state, without an IP address.
I could select in GRUB the older kernel and also that one ended up in the same state, device UP, no IP address.

I need to restore the whole system to continue with it. Hopefully just two hour work.
Comment 4 Freek de Kruijf 2020-11-15 17:18:23 UTC
Tried all kinds of things.
I updated only the kernel-firmware-* packages in the older system. A new image was build, which works OK.
I installed only kernel-default-5.9.1 next to the older kernel. Both have the same problem interface eth0 is UP, but no IPv4 address.
I inspected the added files of the 5.9.1 and did not see any file that would interfere with the older kernel, however starting with the older kernel showed an eth0 interface UP, but no IPv4.
Again removing the 5.9.1 kernel and only having the older kernel, still did not give me an IPv4 address again.
When I install the newest image, openSUSE-Tumbleweed-ARM-JeOS-pine64.aarch64-2020.11.09-Build11.12.raw.xz, I get a system with an IPv6 address, but no IPv4 address like before.
Comment 5 Freek de Kruijf 2020-11-16 14:41:43 UTC
Nov 16 15:20:21.989577 bpim64tumhon wickedd-dhcp4[625]: eth0: Reinitiating DHCPv4 discovery (ifindex 2)
Nov 16 15:20:21.989622 bpim64tumhon wickedd-dhcp4[625]: valid lease: 0; have prefs: 0
Nov 16 15:20:21.989657 bpim64tumhon wickedd-dhcp4[625]: eth0: setting fsm timeout to 64000 msec
Nov 16 15:20:21.989704 bpim64tumhon wickedd-dhcp4[625]: eth0: sending DHCP4_DISCOVER with xid 0xa1b66a5 in state SELECTING
Nov 16 15:20:21.989838 bpim64tumhon wickedd-dhcp4[625]: timeout 4000 adjusted by -571 to 3429 (jr 2000)
Nov 16 15:20:21.989871 bpim64tumhon wickedd-dhcp4[625]: arming retransmit timer (3429 msec)
Nov 16 15:20:22.660834 bpim64tumhon wickedd-dhcp6[635]: timeout 360000 adjusted by -22381 to 337619 (jr 72000)
Nov 16 15:20:22.660897 bpim64tumhon wickedd-dhcp6[635]: arming retransmit timer (337619 msec)
Nov 16 15:20:22.660939 bpim64tumhon wickedd-dhcp6[635]: eth0: advanced xid 0xd68463 retransmission timeout from 360000 to 337619 [-36000 .. 36000]
Nov 16 15:20:22.660975 bpim64tumhon wickedd-dhcp6[635]: eth0: Retransmitting DHCPv6 Info Request
Nov 16 15:20:22.661036 bpim64tumhon wickedd-dhcp6[635]: elapsed-time: 655.35
Nov 16 15:20:22.661091 bpim64tumhon wickedd-dhcp6[635]: client-id: 00:01:00:01:26:d9:b4:31:02:ba:f7:39:24:a4
Nov 16 15:20:22.661166 bpim64tumhon wickedd-dhcp6[635]: oro: info-refresh-time, preference, inf-max-rt, dns-servers, dns-domains, sntp-servers, posix-tz-string, posix-tz-dbname, bootfile-url, bootfile-param
Nov 16 15:20:22.661374 bpim64tumhon wickedd-dhcp6[635]: eth0: INFO-REQUEST message #14, xid 0xd68463 sent with 52 of 52 byte to ff02::1:2
Nov 16 15:20:22.661414 bpim64tumhon wickedd-dhcp6[635]: eth0: xid 0xd68463 retransmitted, next deadline in 57m36.029s
I enabled debugging for wicked in /etc/sysconfig/network/config while using the newest kernel-default-5.9.1-2. Did not see anything strange in the journalctl log. Finally did "journalctl -b -o short-precise -f" and got a repeated patern of messages (see below):

Nov 16 15:20:25.421522 bpim64tumhon wickedd-dhcp4[625]: eth0: retransmit request
Nov 16 15:20:25.421687 bpim64tumhon wickedd-dhcp4[625]: timeout 8000 adjusted by -253 to 7747 (jr 2000)
Nov 16 15:20:25.421721 bpim64tumhon wickedd-dhcp4[625]: arming retransmit timer (7747 msec)
Nov 16 15:20:33.175722 bpim64tumhon wickedd-dhcp4[625]: eth0: retransmit request
Nov 16 15:20:33.175897 bpim64tumhon wickedd-dhcp4[625]: timeout 16000 adjusted by 918 to 16918 (jr 2000)
Nov 16 15:20:33.175933 bpim64tumhon wickedd-dhcp4[625]: arming retransmit timer (16918 msec)
Nov 16 15:20:50.110064 bpim64tumhon wickedd-dhcp4[625]: eth0: retransmit request
Nov 16 15:20:50.110237 bpim64tumhon wickedd-dhcp4[625]: timeout 32000 adjusted by 976 to 32976 (jr 2000)
Nov 16 15:20:50.110273 bpim64tumhon wickedd-dhcp4[625]: arming retransmit timer (32976 msec)
Nov 16 15:21:23.118478 bpim64tumhon wickedd-dhcp4[625]: eth0: retransmit request
Nov 16 15:21:23.118652 bpim64tumhon wickedd-dhcp4[625]: timeout 64000 adjusted by 707 to 64707 (jr 2000)
Nov 16 15:21:23.118692 bpim64tumhon wickedd-dhcp4[625]: arming retransmit timer (64707 msec)
Nov 16 15:21:25.991793 bpim64tumhon wickedd-dhcp4[625]: eth0: timeout in state SELECTING
Nov 16 15:21:25.991857 bpim64tumhon wickedd-dhcp4[625]: eth0: discovery got no (valid) reply, retrying.
Nov 16 15:21:25.991897 bpim64tumhon wickedd-dhcp4[625]: eth0: Reinitiating DHCPv4 discovery (ifindex 2)

I got two global IPv6 addresses, but they do not seem to be alive on the network when I try to ping these addresses on the same network/switch. Also a ping6 from the system gets nothing back. These two addresses are derived from the MAC address and a random number. This would mean the system received data from SLAAC.

Is there anything else I can do?
Comment 6 Freek de Kruijf 2021-04-15 10:43:13 UTC
No problem anymore in this system with the newest Tumbleweed software.