Update broke wired network connection

Today I applied a bunch of updates, and after a reboot, my wired network connection stopped working.

Looking to see if anyone use using anything like this:

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

(from lspci)

is seeing any issues like this? I don’t get DHCP addresses, and static assignments don’t work. Tried wickedd and NetworkManager - no dice either way. Wireless is working fine (it’s how I’m using the machine now - the wireless adapter is an Intel adapter).

dmesg shows the adapter link is up and it identifies the connection as 1 Gbps (which is correct).

Using NetworkManager, I see this in the output from journalctl for the interface:

Nov 12 12:25:45 artifactovol avahi-daemon[1337]: New relevant interface p3p1.IPv6 for mDNS.
Nov 12 12:25:45 artifactovol avahi-daemon[1337]: Registering new address record for fe80::3617:ebff:febb:229d on p3p1.*.
Nov 12 12:26:30 artifactovol NetworkManager[1497]: <warn> [1605212790.0111] dhcp4 (p3p1): request timed out
Nov 12 12:26:30 artifactovol NetworkManager[1497]: <info> [1605212790.0111] dhcp4 (p3p1): state changed unknown -> timeout
Nov 12 12:26:30 artifactovol NetworkManager[1497]: <info> [1605212790.0112] device (p3p1): state change: ip-config -> failed (reason ‘ip-config-unavailable’, sys-iface-state: ‘managed’)
Nov 12 12:26:30 artifactovol NetworkManager[1497]: <warn> [1605212790.0121] device (p3p1): Activation: failed for connection ‘Wired connection 1’
Nov 12 12:26:30 artifactovol NetworkManager[1497]: <info> [1605212790.0123] device (p3p1): state change: failed -> disconnected (reason ‘none’, sys-iface-state: ‘managed’)

I’ve tried removing the interface and letting the system configure it - also didn’t help.

Any ideas?

Hi
It’s getting an IPv6 address, are you expecting IPv4? If you set a static ip address in NetworkManager, does that work? All good here, but I use a static IP in NetworkManager.

I am expecting IPv4 here - I have IPv6 disabled in YaST, actually. I did notice that it reported an address, though, and thought that was odd.

Hi
Reboot the router? Maybe it’s confused?

An IPv6 address might have been configured without benefit of DHCP.
Does look like your machine did issue a DHCP request which wasn’t answered.

So, agree that you should double-check health of your DHCP server/service.
Maybe verify physical connection still good (NIC link indicator light)
Maybe restart your network service, maybe a transient network problem.

TSU

These annoyances occurred on my systems every now and then. Therefore I am switching entirely to networkd/resolved: https://forums.opensuse.org/showthread.php/535416-Minimal-Home-Network-Configuration-with-systemd-networkd?p=2982688#post2982688

Did that. No change.

But I wouldn’t have expected a system that is configured to not use IPv6 to accept an IPv6 address even if the router served one up.

Yep, did all that. Rebooted the machine a couple of times while attempting different things to fix it.

Switched from Wicked to NetworkManager and back.

Thanks, I’ll have a look. I switched from wicked to NetworkManager and back a couple of times to no avail.

What does “ip link” indicate?

  • Does “ip address” show anything?

With “lspci -v”, which kernel module is currently being used?

  • Here with the same controller, the “r8169” kernel module is currently being used …

Using the full hostname indicated by “hostname --fqdn”, what is being indicated by “dig «fully qualified hostname» ANY”?

Thanks for the questions.

$ ip link show p3p1
.
2: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 34:17:eb:bb:22:9d brd ff:ff:ff:ff:ff:ff

lspci -v output (just the ethernet adapter output):

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
Subsystem: Dell Device 05b7
Flags: bus master, fast devsel, latency 0, IRQ 18
I/O ports at d000 [size=256]
Memory at f7d00000 (64-bit, non-prefetchable) [size=4]
Memory at f0000000 (64-bit, prefetchable) [size=16]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169

The hostname actually isn’t resolvable with dig (but this does remind me that I need to update the DNS zone it thinks its in, as I changed it a year ago - but that wasn’t a change that happened with this update).[/size][/size][/size]

Spurious responses are mitigated by defining a static hostname:

**3400G:~ #** hostnamectl  
   Static hostname: 3400G 
         Icon name: computer-desktop 
           Chassis: desktop 
        Machine ID: e7ab772a99a34cfca5aea3fbd011799e 
           Boot ID: e3a167a1f94843688ea0c8586cb37553 
  Operating System: openSUSE Tumbleweed 
       CPE OS Name: cpe:/o:opensuse:tumbleweed:20201110 
            Kernel: Linux 5.9.8-2.ge800bb2-default 
      Architecture: x86-64 
**3400G:~ #**


@hendersj:

As we found out on another thread, for the case of Network Manager, it pays to always define a static hostname because –

  • By default DHCP, as defined in “/etc/dhclient.conf”, always request the host’s name and, the domain name from the DHCP server …
  • The values retrieved are then used by Network Manager as follows:

If a valid static hostname is set, NetworkManager will skip the update of the hostname despite the value of this option. An hostname empty or equal to ‘localhost’, ‘localhost6’, ‘localhost.localdomain’ or ‘localhost6.localdomain’ is considered invalid.

For the case of “Wicked”, it also pays to define a static hostname and, make sure that, in “/etc/sysconfig/network/dhcp” the default settings forDHCLIENT_FQDN_ENABLED
DHCLIENT_FQDN_UPDATE
DHCLIENT6_FQDN_ENABLED
DHCLIENT6_FQDN_UPDATE
DHCLIENT_SET_HOSTNAME
DHCLIENT_HOSTNAME_OPTION
DHCLIENT6_SET_HOSTNAME
DHCLIENT6_HOSTNAME_OPTION

are being used –


DHCLIENT_SET_HOSTNAME="no"
DHCLIENT6_SET_HOSTNAME="no"

[HR][/HR]Caveat: These settings apply to “@Home Networks” – for commercial/business/office networks with professional network routers, the rules laid down by the professional network planners apply …

Thanks again for the assist here. I’ve got the hostname issues sorted out, but it’s still not getting an address on the Ethernet interface for some reason. (Getting the hostname stuff sorted out made sense in general, though the wifi adapter had no issues with getting an address as previously configured, so I didn’t think there was much chance that that would help).

I’ve tried removing/re-adding the adapter again, and did note there was a kernel update today as well. That doesn’t seem to have changed anything, either.

Hi Jim
What about a firmware issue with that card? Or does it really need the r8168 driver and not the r8169… <https://build.opensuse.org/package/show/home:Sauerland:hardware/r8168>

My thoughts as well. Chipset details?

/sbin/lspci -nnk|grep -iA3 net

Anything interesting reported by the following?

dmesg|egrep "r8169|firmware"

I’d be surprised if it was a firmware issue - it worked before the update the day I posted this thread .

Here’s the output of the lspci command:

[jhenderson@artifactovol ~]$ /sbin/lspci -nnk|grep -iA3 net03:00.0 

Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
    Subsystem: Dell Device [1028:05b7]
    Kernel driver in use: r8169
    Kernel modules: r8169
04:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev 73)
    Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4470]
    Kernel driver in use: iwlwifi
    Kernel modules: iwlwifi



I don’t find a module for r8168 - but the selection is (and has been) auto since before the update when things stopped working.

Doesn’t seem to be:


[jhenderson@artifactovol ~]$ sudo dmesg | egrep "r8168|firmware"
    0.144789] Spectre V2 : Enabling Restricted Speculation for firmware calls
    2.674677] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
    8.084513] iwlwifi 0000:04:00.0: loaded firmware version 17.3216344376.0 op_mode iwlmvm

I don’t find a module for r8168 - but the selection is (and has been) auto since before the update when things stopped working.

You won’t. It would need to be added. The r8169 (in-kernel) driver should be sufficient, but perhaps some regression is at play here. The Realtek (r8168) driver is another option that might help for now.

https://software.opensuse.org/search?utf8=✓&baseproject=ALL&q=r8168