Try deleting the connection and adding it again. The details depend on your desktop, but in Gnome, click on the upper-right corner and select one of the connections.

If that doesn't work, post the output from:

$ nmcli

(Obfuscate any MAC addresses, if you don't want them included. Change them to "00:00:00:00:00:00".)

I had the same problem the first time I booted into kernel 4.19.2 and a restart did not fix it. I only have wired internet and in the settings it said "cable not plugged in". After booting into the 4.18 kernel and back into 4.19.2, it did work again. My nmcli output if it is helpful at all: https://paste.fedoraproject.org/paste/fSbrDJ-gm79v-KxZYIGo4w

(In reply to d.vicesss from comment #2)
> ... After booting into the 4.18 kernel and back
> into 4.19.2, it did work again. ...

Thanks for your report.

Andrey: This sounds more like a NetworkManager bug, so I would suggest changing the component to "NetworkManager". (Click the "Component" name at the top of the page to change it. Press backspace to clear the current component name.)

Hi Andrey,

Can you please attach the kernel logs from a 4.19 boot: "journalctl --no-hostname -k -b >dmesg.log"?

See also:

Bug 1654505 - NetworkManager doesn't detect Ethernet connections 

Thomas asks: "What's the output of 

  nmcli connection
  nmcli device
  ip link

?"

Hi,

I am having the same problem and already posted on 
https://ask.fedoraproject.org/en/question/129567/internet-doesnt-work-after-kernel-update-to-4192/

My Networking Informations are here
https://paste.fedoraproject.org/paste/R-CLur0i72Z~SxaO3D14pA

nmcli:

docker0: verbunden to docker0
        "docker0"
        bridge, 02:42:50:B8:AD:52, sw, mtu 1500
        inet4 172.17.0.1/16
        route4 172.17.0.0/16

virbr0: verbunden to virbr0
        "virbr0"
        bridge, 52:54:00:21:8C:74, sw, mtu 1500
        inet4 192.168.122.1/24
        route4 192.168.122.0/24

enp6s0: nicht verfügbar
        "Realtek RTL8111/8168/8411"
        ethernet (r8169), E0:CB:4E:87:ED:1F, hw, mtu 1500

lo: nicht verwaltet
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

virbr0-nic: nicht verwaltet
        "virbr0-nic"
        tun, 52:54:00:21:8C:74, sw, mtu 1500

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: enp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether e0:cb:4e:87:ed:1f brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:21:8c:74 brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:21:8c:74 brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:50:b8:ad:52 brd ff:ff:ff:ff:ff:ff

Hey folks,

Can you test out the kernel in https://bodhi.fedoraproject.org/updates/FEDORA-2018-ce033b4abb? There's a fix for a subset of RTL8111 chips in that kernel that's likely the root cause of this.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.

Fedora 28 has now been rebased to 4.20.5-100.fc28.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29.

If you experience different issues, please open a new bug report for those.

Hi,

after updating the kernel version to one below everything works for me


$ uname -a 

Linux localhost.localdomain 4.19.13-300.fc29.x86_64 #1 SMP Sat Dec 29 22:54:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Thanks for letting us know,