enp2s0 loads and connected, but no ping - boot to Windows NIC works

OpenSUSE Tumbleweed

After recent set of updates some three days ago, after reboot, using DHCP nothing works, manually set IP, netmask, etc., shows a connection but still no ping succeeding.

Reboot into Windows 10, no problem. Even works at 1GB.

I tried booting several older versions of OpenSUSE from grub boot menu.

Also tried several cables, and different ports on switch.

I’ve looked at forums and help places for many hours, tried several things, but to no avail. I’ve tried manual IP, smaller MTU, disabled auto-negotiate trying 100Mbps Full Duplex, blacklisting the module then rebooting and manually loading, etc.

Did networking break for Realtek? (I think I have RTL8111/8168/8411 add-in PCI based NIC but not 100% sure the model, this what I see on POST screen, as I also have an internal NIC that I disabled as it died a few years ago, and I see only 1 Realtek NIC in lspci)?

Using r8169 driver.

[LEFT]Maybe not SW issue, but possibly HW issue, even though it works just fine in Windows??

Help!! :slight_smile:

[/LEFT]

The following recent thread and its solution probably would work for you, too.

https://forums.opensuse.org/showthread.php/537715-Inconsistent-DHCP-Address-Assignment-Using-Wicked?p=2915892#post2915892

Summary:
For those who are multi-booting or use multiple NICs (eg wireless and wired) to connect to their network, it’s essential for a DHCP option to work properly to identify the OS you’re currently running. If this configuration isn’t set correctly on your machine, then the DHCP server won’t identify your machine correctly and may not respond.

TSU

Thanks.

To recap.

System was operational for many months, dual booting Windows 10 and OpenSuse Tumbleweed. Both used DHCP.

After an update, now OpenSuse can’t connect via DHCP, I checked NetworkManager settings, all looks fine.

Dual boot to Windows, no problems there. I am using Windows 10 right now, but if I boot to OpenSuse Tumbleweed, the NIC kernel mode driver loads, but no response from DHCP server if set to DHCP, and not response from ping if set manually.

I tried to manually configure OpenSuse network settings (manual IP, etc.), no change. Reverted to DHCP client, no go either.

Ironically, the status monitor shows packets both ways, but PING doesn’t work at all.

Tried several debug tricks from online, no go.

All I can think of doing now and installing a different NIC into the PCI slot…

Just wondering if anyone else is experiencing enp2s0 issues post recent Tumbleweed updates…

Wayne

Post:

ping -c3 8.8.8.8
ping -c3 google.com
/sbin/lspci -nnk | grep -iA3 net

Please use Code-Tags for the answer.

Thanks, Sauerland. I added a few more commands, in case they are relevant…

After logon to Plasma/X, using a non-admin command line, I get:

wlouie@MeiLi:~> ping -c3 8.8.8.8
ping: connect: Network is unreachable
wlouie@MeiLi:~> ping -c3 google.com
ping: google.com: Name or service not known
wlouie@MeiLi:~> ping 192.168.1.254
ping: connect: Network is unreachable
wlouie@MeiLi:~> /sbin/lspci -nnk | grep -iA3 net
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 01)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168]
        Kernel driver in use: r8169
        Kernel modules: r8169
03:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03)
wlouie@MeiLi:~> ip addr
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: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 9a:b4:f3:d1:74:98 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global noprefixroute enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::d67f:60b7:3e90:d3f5/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ba:6d:1c:9a:cd:cd brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:7e:40:13 brd ff:ff:ff:ff:ff:ff
6: vnet0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UP group default qlen 1000
    link/ether 9e:9c:b6:99:2e:88 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::9c9c:b6ff:fe99:2e88/64 scope link 
       valid_lft forever preferred_lft foreverwlouie@MeiLi:~> 
wlouie@MeiLi:~> ip link
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: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether f4:ec:38:80:de:ef brd ff:ff:ff:ff:ff:ff
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ba:6d:1c:9a:cd:cd brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:7e:40:13 brd ff:ff:ff:ff:ff:ff
6: vnet0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UP mode DEFAULT group default qlen 1000
    link/ether 9e:9c:b6:99:2e:88 brd ff:ff:ff:ff:ff:ff link-netnsid 0
wlouie@MeiLi:~> ip route
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

However, when I first tried the ping commands right after boot up before login to X (Plasma), using a real console and command line (Ctrl-Alt-F1, logged in as admin), it seems I get “Destination host not reachable” which is odd, since I think that should happen with fixed IP, and the “Network not reachable” should happen with DHCP not working, yet, it seems I have the reverse… Don’t know how to copy console screen.

As in:

wlouie@MeiLi:~> ping -c3 8.8.8.8
ping: connect: Destination host not reachable

But once I was logged into Plasma, the real console command started to behave the same as the Plasma/X command line, that is, “Network not reachable”. I can try to replicate again later if this point is relevant in any way.

I’m at a loss… DHCP Client or manual IP values have same results (no network traffic) but different ping response (due to network up but not functional with manual IP, versus network down with DHCP, though the results above herein seem to be opposite to that, but consistent in previous OpenSuse Tumbleweed reboots).

I have to reboot into Windows on this system to reply to this forum :slight_smile:

Next time, I’ll use my laptop to reply, so I don’t have to reboot.

Cheers

P.S. After the updates a couple of days ago, I rebooted and I think all was well (I normally check after “zypper dup” updates, using a reboot). I then moved back to my home a day later (was away for 3 months at a room in my away location) and connected to another router (my home router) on which these issues are now happening, though this system was on that router before (on both home and away routers off and on over the last 6+ months). This is the first time it has failed here, and I am unable to return to the away location but I can try setting up the away router and hook up this system to it, though it will have a slightly different configuration - bridge to my home router instead of bridge to the DSL at my away location - I used bridged mode at away location because there was no wire from DSL to my room, but I do have wires from home router to this PC via a GB switch).

Maybe wrong route?

The OP’s posted route information doesn’t show any routing for the IP subnet assigned to enp2s0.

…and no default route present either.

I fixed the default route, looking to how to correct assigned subnet>

I just use Network Manager, usually with Automatic everything (though I did try some manual versions).

I never changed anything between working and not working, it used to work as is… My attempts to make it work is when I tried making changes to make it work.

It’s not a routing problem,
It’s a network configuration problem on or very near the machine because you don’t have connectivity on the local network (192.168.1.0/24).

Try pinging localhost

ping -c3 127.0.0.1

and your assigned network address

ping -c3 192.168.1.3

Also,
Am curious what ip address your Windows machine has (Is it also 192.168.1.3?)
In Windows you would run

ipconfig

I’d also repeat my previous post and check whether you have the appropriate entry in that xml file.

TSU

Maybe my router, as other strange things are happening on the LAN.

I have a new router I’ll try in the morning…

Thanks everyone, I’ll update this thread when I know better…

That’s strange because your ethernet interface is assigned with 192.168.1.3/24, and I assumed you had manually assigned this address to the interface.

That would only have relevance if the OP was using wicked, and he’s already mentioned that he’s using NetworkManager, (although it might be sensible to check that both services are not running concurrently for some reason).

Looked at this.
My default, it appears that NM does not enable rfc2132, you can see this by roughly the following steps. I couldn’t successfully configure and reload, but maybe someone will see what I did wrong. In the following commands, I don’t use the entire command or object names, it’s supposed to be enough to type enough characters to uniquely identify what you want to do.

The following are run as a normal User, and use sudo only as necessary.

First, display the configured connections on your machine. By default, the NAME of the connection on my machine contains spaces which makes it difficult to use, so I used the displayed UUID for later commands

nmcli con show

Opening the nmcli interactive editor, the following command will list valid connection types. My guess is that most people will choose “ethernet” or “802-11-wireless”

nmcli con edit

You can now type only “print” at the nmcli prompt to display all the settings for this connection, and you will find “ipv4.dhcp-client-id” not set to anything

nmcli > print

For an explanation of what you can do with the ipv4.dhcp-server-client-id option, you can type the following. Note that we won’t want to insert the MAC address because that’s the problem when multi-booting

nmcli> describe ipv4.dhcp-client-id

Exit the interactive nmcli editor with

nmcli> quit

The following command should modify the setting, I chose an arbitrary text string “openSUSE” that can be anything. Note that you have to insert your unique UUID string for the connection which was displayed in the above “show” command

nmcli con modify **UUID_string **ipv4.dhcp-client-id openSUSE

And reload your changes

sudo nmcli reload

Unfortunately,
When I repeat the steps to view the dhcp-client-id setting, it’s unchanged.
Maybe someone can identify what I’m doing wrong and complete this likely necessary modification.

TSU

Easier to check with ‘nmcli c show <connection_name> |grep ipv4.dhcp-client-id’

For example, I have connection named DHCP…

nmcli c show DHCP|grep ipv4.dhcp-client-id

To modify it do something like

nmcli c modify DHCP ipv4.dhcp-client-id openSUSE

I was prompted for root credentials (by polkit). After that the modification was complete
then check again

nmcli c show DHCP|grep ipv4.dhcp-client-id 
ipv4.dhcp-client-id:                    openSUSE

And of course one could just edit the connection profile (eg /etc/NetworkManager/system-connections/) directly and add the required…

[ipv4]
dhcp-client-id=openSUSE

It will take effect when the connection is next activated.

Also, for those who prefer GUI, the same can be achieved via the graphical NM connection editor.

That command querying using “show” works for me, too…
And yet when I ran the “print” command again it still didn’t reflect the change and setting.

guess that’s a bug…

And yes, the change shows up in the Network Manager GUI as well…

TSU

Some interesting results.

Manually configure IP, netmask, etc., then for about 1-2 minutes after rebooting the router, I can ping the router and do web, but after that, ping fails (host unreachable). If I try DHCP, even after reboot router, it’s “worse” in that there’s no network (failed to get IP, default route, etc.).

Plug in new NIC (USB version), different driver, and try same technique. Manual works for a minute or so after rebooting router, but fails after that (host unreachable), and DHCP always fails completely.

If I add a new AP on the LAN, using just the LAN side of the AP (not the WAN port), but leave the DHCP server on (with a different range), then manual works for a minute or so, and so does DHCP for a minute or so (getting IP from AP not router).

If I reboot into Windows 10, everything works fine, for both the original NIC and the USB NIC, as well as manual and DHCP, with either “just the router” or “router and AP”.

It’s odd that it works for a minute or so in manual mode, both NICs (as well as DHCP if from the AP).

Pinging to the AP after the 1 minute also fails, so I can’t use the AP to replace my router…

Can you confirm that you only have one network management framework active?

sudo systemctl status NetworkManager
sudo systemctl status wicked
sudo systemctl status systemd-networkd.service

I ran the three checks, only NetworkManager is active / running. The other 2 are dead / inactive.