I have following issue but I do not know were I can find useful logs to understand what is going on.
My machine is a very standard Gigabyte Mainboard with integrated Ethernet. Only one NIC is present on the system. The issue started about 3 month ago, I always wanted to investigate but I am too annoyed now, so I really want to solve it.
Take a typical start up: the machine is on a dlan Ethernet were a Devolo 1200 (with a small OpenWRT like OS running on it) is managing the Ethernet interface. When I start up, the system (with wicked as network setup, there is no WLAN on the machine) boots fine. But when arriving at the Plasma desktop you have no network. If you try to restart networking services (e.g. sudo rcnetwork restart) it does but you do not have network. I also tried to restart every wicked service in yast but no network and no error log.
But if you simply reboot the machine all works as expected.
Now I tried this also without a graphical user session, it is the same, so the issue is IMO not bound to Plasma. I thought it might be that this is a timeout with the dlan being in energy saving at the first bood and awaken at the second. But wouldn't wicked wait until the interface has an address? Wouldn't it complain logging clearly in journalctl? Anybody else in the past encountered such an issue?
Thank you in advance.
On 16/12/2021 09.47, Stakanov wrote:
I have following issue but I do not know were I can find useful logs to understand what is going on.
My machine is a very standard Gigabyte Mainboard with integrated Ethernet. Only one NIC is present on the system. The issue started about 3 month ago, I always wanted to investigate but I am too annoyed now, so I really want to solve it.
Take a typical start up: the machine is on a dlan Ethernet were a Devolo 1200 (with a small OpenWRT like OS running on it) is managing the Ethernet interface. When I start up, the system (with wicked as network setup, there is no WLAN on the machine) boots fine. But when arriving at the Plasma desktop you have no network. If you try to restart networking services (e.g. sudo rcnetwork restart) it does but you do not have network. I also tried to restart every wicked service in yast but no network and no error log.
But if you simply reboot the machine all works as expected.
Now I tried this also without a graphical user session, it is the same, so the issue is IMO not bound to Plasma. I thought it might be that this is a timeout with the dlan being in energy saving at the first bood and awaken at the second. But wouldn't wicked wait until the interface has an address? Wouldn't it complain logging clearly in journalctl? Anybody else in the past encountered such an issue?
I would investigate in a console before plasma login. Ie, ctrl-alt-f1, login as root, then find out what exactly is failing.
Can you ping the router by IP number?
If yes, then investigate DNS and routing. Ping 8.8.8.8, and ping google.com, for instance.
If not, is interface up? check logs. "Do "ifconfig" if installed, or modern equivalent.
On Thu, 16 Dec 2021 09:47:19 +0100 Stakanov stakanov@disroot.org wrote:
I have following issue but I do not know were I can find useful logs to understand what is going on.
My machine is a very standard Gigabyte Mainboard with integrated Ethernet. Only one NIC is present on the system. The issue started about 3 month ago, I always wanted to investigate but I am too annoyed now, so I really want to solve it.
Take a typical start up: the machine is on a dlan Ethernet were a Devolo 1200 (with a small OpenWRT like OS running on it) is managing the Ethernet interface. When I start up, the system (with wicked as network setup, there is no WLAN on the machine) boots fine. But when arriving at the Plasma desktop you have no network. If you try to restart networking services (e.g. sudo rcnetwork restart) it does but you do not have network. I also tried to restart every wicked service in yast but no network and no error log.
But if you simply reboot the machine all works as expected.
Now I tried this also without a graphical user session, it is the same, so the issue is IMO not bound to Plasma. I thought it might be that this is a timeout with the dlan being in energy saving at the first bood and awaken at the second. But wouldn't wicked wait until the interface has an address? Wouldn't it complain logging clearly in journalctl? Anybody else in the past encountered such an issue?
Thank you in advance.
I have no experience with powerline adapters. I did use to use wicd and liked it above others, but I have stopped since it is apparently no longer maintained. Why do you need a network manager at all if you only have one directly wired network connection? Anyway, NM and systemd-networkd are available.
I would investigate in a console session, don't bring up the graphical interface.
And I don't understand what you mean by 'typical startup' that doesn't work and 'reboot' that does. How is one boot different from another?
In data giovedì 16 dicembre 2021 11:15:49 CET, Dave Howorth ha scritto:
I would investigate in a console session, don't bring up the graphical interface.
And I don't understand what you mean by 'typical startup' that doesn't work and 'reboot' that does. How is one boot different from another?
This meant: boot, select in grub the OS, continue until SDDM.
Then it is indifferent if you go to plasma or to F1, you will have no internet connection on the eth0. What I have to find out is why.
Reboot: once you are at any time in the boot process, AFAIK if you do ctl+alt+del (ctrl+alt+canc) then you will reboot and then...all works.
What is puzzling me is that a restart of wicked does not do any difference. So I will try now on the tty1 with root. Problem is that after the "modern" programs took place, I am lost with the syntax as I never understood the advantage. E.g. ss seem to give a much less intelligible output.
Op donderdag 16 december 2021 13:31:42 CET schreef Stakanov:
This meant: boot, select in grub the OS, continue until SDDM.
Then it is indifferent if you go to plasma or to F1, you will have no internet connection on the eth0. What I have to find out is why.
Go into the Networkmanager settings for your connection and set it to be used by all users. If encryption is used make sure the passphrase is stored in plain text ( it's rw for root only ). Apply, reboot and at login the connection will be present.
OK, some more insight maybe. Unlike what I thought (I did not remember) I have two NIC on that system. It appears that either the NIC of the mainboard is broken or the driver has an issue. Currently I have deactivated the NIC of the mainboard and the problems went away. Curiously that also made me have an issue with the monitor settings, which I had to restore after a reboot. The NIC now is running on the PCI-e version 1 short lane of the board. As of now, the address is correctly acquired and the card works.
silversurfer:~ # lspci | egrep -i --color 'network|ethernet' 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection which is now the working one.
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) which was the faulty / not working one.
# lshw -class network *-network DISABLED description: Ethernet interface product: 82574L Gigabit Network Connection vendor: Intel Corporation physical id: 0 bus info: pci@0000:05:00.0 logical name: enp5s0 version: 00 serial: 68:05:ca:61:93:8f capacity: 1Gbit/s width: 32 bits clock: 33MHz capabilities: pm msi pciexpress msix bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=5.15.7-1-default firmware=1.8-0 latency=0 link=no multicast=yes port=twisted pair resources: irq:49 memory:fe7c0000-fe7dffff memory:fe700000-fe77ffff ioport:d000(size=32) memory:fe7e0000-fe7e3fff memory:fe780000-fe7bffff
*-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:06:00.0 logical name: enp6s0 version: 06 serial: fc:aa:14:09:76:16 size: 1Gbit/s capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=5.15.7-1-default duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s resources: irq:53 ioport:c000(size=256) memory:fe600000-fe600fff memory:d0000000-d0003fff
So enp6s0 was active the other (intel) was not when the problem occurred. more info on it:
# ethtool enp6s0 Settings for enp6s0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown Supports Wake-on: pumbg Wake-on: d Link detected: yes
What was configured: # ip a 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: enp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 68:05:ca:61:93:8f brd ff:ff:ff:ff:ff:ff 3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 link/ether fc:aa:14:09:76:16 brd xx:xx:xx:xx:xx:xx 4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 82:ed:79:e2:e7:4f brd xx:xx:xx:xx:xx:xx inet 192.168.xxx.xx/xx brd 192.168.xx.xx scope global br0 valid_lft forever preferred_lft forever inet6 fd00::56xx:21xx:8dxx:xxxx/64 scope global temporary dynamic valid_lft 7119sec preferred_lft 3519sec inet6 fd00::80xx:79xx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 7119sec preferred_lft 3519sec inet6 20xx:xx:6fxx:6xx0:2xx7:5xx8:5f7c:e7xx/64 scope global temporary dynamic valid_lft 7119sec preferred_lft 1230sec inet6 2xxx:c9:xx21:xx00:80ed:xxff:xxe2:xx4f/64 scope global dynamic mngtmpaddr valid_lft 7119sec preferred_lft 1230sec inet6 xx80::xxxx:79ff:fee2:xxxf/64 scope link valid_lft forever preferred_lft forever
when this occured I cannot ping the dlan on its address, nor to I obviously reach the router. The interface card seems to be recognized correctly.
Here below is the output of the pci-e card when rebooted (still not network).
closing yast takes a lifetime. In the journalctl you find: ec 19 10:16:36 fritz.box systemd[1]: Reloaded wicked managed network interfaces. Dec 19 10:16:36 fritz.box wicked[8832]: br0 setup-in-progress Dec 19 10:16:36 fritz.box wicked[8832]: enp6s0 enslaved Dec 19 10:16:36 fritz.box wicked[8832]: br0 device-ready Dec 19 10:16:05 fritz.box firewalld[1151]: WARNING: NOT_ENABLED: br0 Dec 19 10:16:05 fritz.box ModemManager[1150]: <info> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:07.0/0000:05:00.0': not supported by any plugin Dec 19 10:16:05 fritz.box ModemManager[1150]: <info> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:09.0/0000:06:00.0': not supported by any plugin Dec 19 10:16:05 fritz.box systemd[1]: Reloading wicked managed network interfaces... Dec 19 10:16:02 localhost systemd-udevd[8737]: Using default interface naming scheme 'v249'. Dec 19 10:16:02 localhost systemd-udevd[8735]: Using default interface naming scheme 'v249'. Dec 19 10:16:02 localhost systemd-udevd[8736]: Using default interface naming scheme 'v249'. Dec 19 10:15:48 localhost systemd[1]: snapperd.service: Deactivated successfully. Dec 19 10:14:47 localhost systemd[1]: Started DBus interface for snapper.
What else: during the startup you are getting a warning that i2c-10 timeout! and "failed reset at the end of transaction". (I think the latter on i2c-11).
As this message vanishes when I deactivate the NIC of the board but is still there when I deactivate the other, I went by deduction for the solution that the controller is either broken or the Realtech driver has a problem. If you see other people complaining about Realtech network card issues, you may think about this post.
What is noteworthy: the mointor settings are lost in plasma when changing the ethernet port (enp6s0 vs. enp5s0 and vice versa) Which puzzles me because I do not see how monitor settings should react on ethernet ports. IRQ or internal address issue? In all cases this is solved by deactivating the controller on the mainboard.
On 21.12.2021 12:12, Stakanov wrote:
OK, some more insight maybe. Unlike what I thought (I did not remember) I have two NIC on that system. It appears that either the NIC of the mainboard is broken or the driver has an issue. Currently I have deactivated the NIC of the mainboard and the problems went away. Curiously that also made me have an issue with the monitor settings, which I had to restore after a reboot. The NIC now is running on the PCI-e version 1 short lane of the board. As of now, the address is correctly acquired and the card works.
silversurfer:~ # lspci | egrep -i --color 'network|ethernet' 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection which is now the working one.
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) which was the faulty / not working one.
Always use "lspci -nn" to show numerical IDs. Description is usually useless. Realtek could be a problem and to check what driver is needed/recommended information about actual device is needed.
On Thursday, 16 December 2021 08:47:19 GMT Stakanov wrote:
I have following issue but I do not know were I can find useful logs to understand what is going on.
My machine is a very standard Gigabyte Mainboard with integrated Ethernet. Only one NIC is present on the system. The issue started about 3 month ago, I always wanted to investigate but I am too annoyed now, so I really want to solve it.
Take a typical start up: the machine is on a dlan Ethernet were a Devolo 1200 (with a small OpenWRT like OS running on it) is managing the Ethernet interface. When I start up, the system (with wicked as network setup, there is no WLAN on the machine) boots fine. But when arriving at the Plasma desktop you have no network. If you try to restart networking services (e.g. sudo rcnetwork restart) it does but you do not have network. I also tried to restart every wicked service in yast but no network and no error log.
But if you simply reboot the machine all works as expected.
Now I tried this also without a graphical user session, it is the same, so the issue is IMO not bound to Plasma. I thought it might be that this is a timeout with the dlan being in energy saving at the first bood and awaken at the second. But wouldn't wicked wait until the interface has an address? Wouldn't it complain logging clearly in journalctl? Anybody else in the past encountered such an issue?
Thank you in advance.
I think this one is still in the information gathering stage. Others have suggested looking at a console session. I would suggest taking a look at whether the BIOS has anything to do with the problem. Perhaps power up and reboot when GRUB comes up and see whether the problem is still there? Plus take a look at the BIOS settings for the ethernet interface.
Another thing to try is to place an ethernet switch between the Devolo 1200 and the PC, to see whether the BIOS is just ignoring the ethernet interface because it thinks nobody is at home in the Devolo 1200.
Sorry for asking maybe stupid things.
When postin the output of network configuration, is it a security risk to post ipv6 addresses? Should I obfuscate them partially or is it indifferent.
On 17/12/2021 10.40, Stakanov wrote:
Sorry for asking maybe stupid things.
When postin the output of network configuration, is it a security risk to post ipv6 addresses? Should I obfuscate them partially or is it indifferent.
If it is a public and fixed one, you could use ellipsis. If the exact address is relevant, someone will tell you so :-)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
Knurpht-openSUSE -
mark neidorff -
Stakanov -
Vince Littler