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 
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).