GerBra
Um erstmal die Fragen zu beantworten, eine Firewall ist installiert aber nicht aktiv. Das linux-firmware-Paket ist installiert. Wie man einen anderen Kernel installiert, im Boot-Manager einträgt und dann testet, habe ich noch nicht versucht, aus der Befürchtung, etwas falsch zu machen und dann gar nichts mehr geht. Ein MAC-Changer läuft nicht, dafür sind im Router nur die MAC-Adressen der zugreifenden Geräte zugelassen. Auf dem Rechner ist auf einer 2.Platte Windows11 installiert, das keinerlei Probleme mit der Netzwerkverbindung hat. Hier die Ausgabe von pacman -Qs xdg-desktop-portal:

local/xdg-desktop-portal 1.16.0-3
    Desktop integration portals for sandboxed apps
local/xdg-desktop-portal-gtk 1.14.1-1
    A backend implementation for xdg-desktop-portal using GTK
local/xdg-desktop-portal-kde 5.27.7-1 (plasma)
    A backend implementation for xdg-desktop-portal using Qt/KF5

Und nun zu dem, was ich inzwischen selbst im Internet zusammensuchte und probierte und von dem man sagen könnte, etwas hat sich verbessert, d.h. die Wartezeit bis "Netzwerk-aktiv" ist im Durchschnitt weniger geworden (von Null bis ca. 1 Minute) aber ich weiss nicht, warum. Das ist zunächst eine conf-Datei unter etc/NetworkManager/conf.d mit dem Inhalt:

# bat /etc/NetworkManager/conf.d/99-carrier.conf
[main]
ignore-carrier=yes

und ein Eintrag in die bis dahin leere Datei NetworkManager.conf mit:

[main]
ignore-carrier=yes

Und zusätzlich die Installation des "nm-connection-editors" (auch wenn der von KDE auch einiges kann). Wie gesagt, steht mal die Verbindung, ist sie stabil. Jetzt habe ich jedoch mal aus Neugierde diese stabile Verbindung per Hand via nmcli device disconnect eno1 getrennt und wollte sie gleich wieder mit nmcli device connect eno1 oder nmcli device up eno1 verbinden. In beiden Fällen kommt die Fehlermeldung:

Fehler: Neue Verbindung konnte nicht hinzugefügt/aktiviert werden: 
Connection 'eno1' is not available on device eno1 because device has no carrier

Unter dem Befehl: nmcli connection up *uuid* kommt die Fehlermeldung:

Fehler: Aktivierung der Verbindung ist gescheitert: No suitable device found for this connection 
(device eno1 not available because device has no carrier).

Diese Meldung entspricht auch der Meldung nach Boot, wenn die Verbindung noch nicht da ist ("no carrier"), jedoch kann das nicht sein, da das Kabel natürlich eingesteckt und in Ordnung und der Router
auch richtig konfiguriert ist. Aktivieren lässt sich die Verbindung jetzt jedoch wieder mit:

sudo systemctl stop NetworkManager.service
sudo modprobe -rfv e1000e (oder "sky2")
sudo modprobe -v e1000e (oder "sky2")
sudo systemctl start NetworkManager.service

Sobald ich mal wieder einen sehr langen Verbindungsaufbau von mehreren Minuten habe, werde ich das log auf pastebin posten und hier Bescheid geben.
Eine Sache würde ich noch probieren, weiss aber nicht, ob es sinnvoll ist und vor allem, wie. Ich würde mal den aktuellsten Intel-Treiber für den im Rechner verbauten Netzwerkadapter (Intel i219-lm) installieren, und zwar diesen. Mir fiel nämlich bei der Suche auf, der die Intel I21x-Adapter ziemliche Probleme mit Linux zu haben scheinen. Die im Vergleich zu Windows langsamere Geschwindigkeit ist mir auch schon aufgefallen, jedoch funktionierte die Lösung aus dem Hetzner-Link hier nicht.

  • GerBra hat auf diesen Beitrag geantwortet.

    Was ist nic-speed-fix.service?

    • GerBra hat auf diesen Beitrag geantwortet.
    • GerBra gefällt das.

      Gut, ein paar Überlegungen die ich hatte sind durch deine Infos weggefallen.

      Ich habe dein (teilweises) Log nunmal zusammengeführt und würde sagen:
      eno1 bekommt wirklich sehr spät (warum?) einen Carrier.
      Grob gesagt:

      • System bootet ab: 17:58:33
      • 17:58:34 startet NetworkManager (wie es sein sollte)
      • Hat aber (nach dem mittels dbus die NIC erkannt/gehandelt wird) Probleme:
      • 17:58:34 archlinux NetworkManager[299]: <info> [1692892714.8137] device (eno1): state change: unmanaged -> unavailable (reaso> (Hier fehlt leider der Rest der Zeile, da Pager) die NIC in Status UP zu setzen und/oder einen Carrier herzustellen.
      • Das geschieht letztendlich erst (nach "händischem Zutun"?):
      • 18:00:01 mit einem ersten Versuch, der den Verlauf "unavailable -> disconnected" konstatiert, und weiter um 18:00:04 dann den Carrier plus Link aufbaut, aber nur mit 10 Mbps Full Duplex (statt 1000 Mbps)

      Diese Auswirkung erklärt dann auch die geringe Geschwindigkeit. Das PC(Nic)<->Router(Switch) keinen stabilen initialen Link herstellen/aushandeln können hat ggf. die Auswirkung das immer oder oftmals der minimal mögliche Link-Modus verwendet wird.

      Berni341 Eine Sache würde ich noch probieren, weiss aber nicht, ob es sinnvoll ist und vor allem, wie. Ich würde mal den aktuellsten Intel-Treiber für den im Rechner verbauten Netzwerkadapter (Intel i219-lm) installieren, und zwar diesen.

      Das würde ich dir nicht raten, v.a. da du nicht weißt wie. "Treiber" unter Linux werden diametral anderst gehandhabt als z.B. unter Windows diese zu "installieren". Außerdem:
      Diese verlinkte Version ist von 2020. Wir haben 23 und sind bei Kernel 6.4.12. Intel pflegt/entwickelt seine Linux-Treiber mehr oder weniger selbst im Kernel, da sind nahezu sicher alle aktuellen Änderungen heutzutage drin. Ich verspreche mir keine Änderung dadurch.
      Genauso (zeitlich, versionsbezogen) mußt du ggf. andere Fundstellen/Reports einordnen, eine Fundstelle mit den ggf. gleichen "Symptomen" von vor 10 Jahren wird kaum die gleiche Ursachen/Notlösungen haben wie der aktuelle Stand. Dafür gibt es mit zunehmender Komplaxität eher neue "Probleme", IMHO v.a. Regressionen, also Ursache durch Zusammenspiel von Hardware/Bussystemen die augenscheinlich erstmal nichts miteinander zu tun haben.
      Der Link https://bugzilla.kernel.org/show_bug.cgi?id=213377 scheint mir da noch am ehesten - auch zeitlich - in die Richting zu gehen.

      Nochmal nachfragen:
      Die "schlechte" Geschwindigkeit hast du aktuell gerade bzw. immer?

      Poste doch mal die Ausgaben von:

      lspci -vv | curl -F 'file=@-' 0x0.st
      ethtool eno1
      ethtool -S eno1

      Erster Befehl stellt die Ausgabe von lspci -vv auf den Pastebin-Server, du bekommst einen Link zurück.
      Die beiden anderen zeigen Infos über den Status deiner Nic, es kann sein das du das Paket ethtool installieren mußt wenn nicht vorhanden.

      Bei ethtool ist v.a. interessant(erster Befehl): Mit welchem Link-Modus (sollte 1000M/FD sein) wird der Carrier hergestellt. Du kannst damit auch mal prüfen, ob du z.B. manchmal die volle Geschwindigkeit kriegst, oder wenn es mal wieder länger dauert bzw. "langsam" ist, ob dann nur 10M/FD genutzt werden.
      Der zweite ethtool-Befehl zeigt Statistiken, hier würde mich v.a. interessieren ob es nach einer gewissen Nutzungszeit (egal in welchem Zustand: ok, langsam, dauert lange bis,...) irgendwelche RX/TX/Carrier Fehler gibt. Da lohnt es sich für dich auch je nach "Zustand" immer mal reinzusehen ob es mehr oder weniger Fehleranzahl wird.

      schard Was ist nic-speed-fix.service?

      Aufmerksam! Habe ich glatt übersehen...
      Dieser Service muß ja IMHO von dir kommen, was macht der genau?

      • Berni341 hat auf diesen Beitrag geantwortet.

        GerBra
        Zum Thema nic-speed-fix.service muss ich auf diesen Forenbeitrag verweisen. Die lahmen 10MBit sind nicht zufällig, aber wenn von diesen unter Linux wegen des NICs auch noch weniger bereit stehen, wirds eng. Das wäre dann das nächste Problem, aber ich möchte mich hier nur um die verlangsamte Bereitstellung des Netzwerks kümmern. Da in den eineinhalb Tagen bislang das Problem nicht mehr so schwer aufgetreten ist, wie zuvor, kann ich dazu kein log posten. Scheinbar hat eine der zuvor genannten Maßahmen die Situation verbessert oder es war nur Zufall, dass bis jetzt nach Neustart oder "Abmelden - wieder Anmelden" keine minutenlange Wartezeit mehr auftrat. Was mir bei den (älteren und inzwischen gelöschten) logs auffiel, war, dass scheinbar ein KDE-eigener Service die Wartezeit zu verursachen schien. So wie oben die nur etwas längere Zeit zwischen
        17:59:46 archlinux dbus-daemon[478]: [session uid=1000 pid=478] Activated service 'org.kde.KSplash' failed: Process org.kde.KS>
        und
        Aug 24 18:00:01 archlinux NetworkManager[299]: <info> [1692892801.7100] device (eno1): carrier: link connected
        waren es z.B auch mal rund 3 Minuten (in einem anderem log als dem oben geposteten) zwischen NetworkManager[313]: <info> [1688022390.2014] agent-manager: agent[652f727ebec76ab4,:1.40/org.kde.plasma.networkmanagement/1000]: agent registered
        und
        NetworkManager[313]: <info> [1688022552.3214] device (eno1): carrier: link connected
        Sobald ich wieder eine grössere Wartezeit habe, werde ich das log-File bereitstellen.

        • GerBra hat auf diesen Beitrag geantwortet.

          Berni341 Zum Thema nic-speed-fix.service muss ich auf diesen Forenbeitrag verweisen

          Telefonkabel? Im Ernst?

          Dann brauchen wir mit "Diagnose" garnicht groß weitermachen.
          Eine heutige Nic (gerade Gigabit) braucht ein intaktes, passendes, vollständig geschaltetes Patchkabel. Punkt. Alles andere ist Dschungel-Camp...

          NB: Diese KDE-Splash Meldung (war auch mein Gedanke) findet sich in diversen anderen Logfiles genauso. Allerdings geht es da kontinuierlich danach weiter, ist also keine Ursache.

          Und: wäre es so aufwendig gewesen, die geforderten Infos trotzdem zu posten?

          • Berni341 hat auf diesen Beitrag geantwortet.

            GerBra
            Was sowohl Bereitstellung der Netzverbindung als auch durchschnittliche Geschwindigkeit angeht, habe ich den Vergleich mit Windows. Netz ist gleich da und Geschwindigkeit entspricht der Einstellung. Bei (allen getesteten) Linux-Distros ist die Bereitstellung der Netzwerkaktivität (bis vor 1,5 Tagen) extrem verzögert und die Geschwindigkeit entspricht, wie in den oben geposteten Links und noch vielen anderen Berichten bezüglich des Intel-NICs unter Linux, nur ca. 70% der tatsächlichen Netzgeschwindigkeit. Dabei ist es unerheblich, ob der Rechner an einer 10MBit oder 10BGit-Leitung hängt. Da sich die geforderten Infos, wie geschrieben, auf die Geschwindigkeit und nicht auf die Bereitsstellung des Netzwerks bezogen, habe ich darauf verzichtet, reiche jedoch hier ethtool eno1 und ethtool -S eno1 nach:

            Settings for eno1:
                    Supported ports: [ TP ]
                    Supported link modes:   10baseT/Half 10baseT/Full
                                            100baseT/Half 100baseT/Full
                                            1000baseT/Full
                    Supported pause frame use: Symmetric Receive-only
                    Supports auto-negotiation: Yes
                    Supported FEC modes: Not reported
                    Advertised link modes:  Not reported
                    Advertised pause frame use: No
                    Advertised auto-negotiation: No
                    Advertised FEC modes: Not reported
                    Speed: 10Mb/s
                    Duplex: Full
                    Auto-negotiation: off
                    Port: Twisted Pair
                    PHYAD: 1
                    Transceiver: internal
                    MDI-X: off (auto)
            netlink error: Operation not permitted
                    Current message level: 0x00000007 (7)
                                           drv probe link
                    Link detected: yes
            NIC statistics:
                 rx_packets: 2098
                 tx_packets: 1677
                 rx_bytes: 2444979
                 tx_bytes: 209659
                 rx_broadcast: 48
                 tx_broadcast: 3
                 rx_multicast: 3
                 tx_multicast: 8
                 rx_errors: 1020
                 tx_errors: 0
                 tx_dropped: 0
                 multicast: 3
                 collisions: 0
                 rx_length_errors: 0
                 rx_over_errors: 0
                 rx_crc_errors: 1020
                 rx_frame_errors: 0
                 rx_no_buffer_count: 0
                 rx_missed_errors: 0
                 tx_aborted_errors: 0
                 tx_carrier_errors: 0
                 tx_fifo_errors: 0
                 tx_heartbeat_errors: 0
                 tx_window_errors: 0
                 tx_abort_late_coll: 0
                 tx_deferred_ok: 0
                 tx_single_coll_ok: 0
                 tx_multi_coll_ok: 0
                 tx_timeout_count: 0
                 tx_restart_queue: 0
                 rx_long_length_errors: 0
                 rx_short_length_errors: 0
                 rx_align_errors: 0
                 tx_tcp_seg_good: 0
                 tx_tcp_seg_failed: 0
                 rx_flow_control_xon: 0
                 rx_flow_control_xoff: 0
                 tx_flow_control_xon: 0
                 tx_flow_control_xoff: 0
                 rx_csum_offload_good: 2073
                 rx_csum_offload_errors: 0
                 rx_header_split: 0
                 alloc_rx_buff_failed: 0
                 tx_smbus: 0
                 rx_smbus: 0
                 dropped_smbus: 0
                 rx_dma_failed: 0
                 tx_dma_failed: 0
                 rx_hwtstamp_cleared: 0
                 uncorr_ecc_errors: 0
                 corr_ecc_errors: 0
                 tx_hwtstamp_timeouts: 0
                 tx_hwtstamp_skipped: 0

            Du hast uns immer noch nicht gezeigt, was in nic-speed-fix.service steht.

            • Berni341 hat auf diesen Beitrag geantwortet.

              Geschwindigkeit und Bereitstellung sind aber Prozesse, die Hand in Hand gehen. Ich würde sagen: Das Aushandeln bzw. das Scheitern bedingen zum Einen die "offensichtliche" Verbindungs(lang)dauer, was einhergeht mit der mangelnden Geschwindigkeit. Und:
              rx_packets: 2098
              ...
              rx_crc_errors: 1020
              Fast 50% der emfangenen Pakete müssen erneut initiert werden wegen Übertragungs/Checksummen-Fehler. Die "Leitung" ist einfach nicht sauber.

              Du bist an diese Gegebenheiten gebunden? D.h. du mußt den Link-Modus auf 10Mbs beschränken? Und du bist an diese (was auch immer) Verkabelung gebunden?
              Gäbe es die Möglichkeit, den Rechner mal mit einem ordentlichen CAT-5-Kabel an den Router anzuschließen zu Testzwecke? Der Router hat doch wohl einen GB-Switch eingebaut?

              @schard :
              Ich vermute nun, in dem nic-speed Service stellt Bernie den Link-Modus auf 10Mbs fix ein. Trotzdem wäre es wichtig den Service und was ausgeführt wird mal zu sehen (v.a. da der im alten Log nicht lief scheinbar).
              Der Network-Manager könnte mit dieser Einstellung jetzt ggf. Probleme (Verzögerung) haben, wenn dieser den Link ebenfalls nochmal von Grund auf initieren will.

              Evtl. wäre es ein Ansatz, komplett auf alle "Managers" zu verzichten und mit "Bordmitteln" (ip, dhcpcd/dhclient) einen eigenen Service zu nutzen.

              @Berni341
              Bitte auch nochmal dein aktuelles Network-Manager Konfig für "Kabellose Verbindung" posten. Nutzt du eine statische IP oder eine per DHCP zugeteilte?

              Und:
              Bitte den o.a. lspci Aufruf nachreichen. Es gibt eine vage Chance daß ein Fix aus dem bugzilla-Link ggf. helfen könnte. Dafür müßte man aber bestimmte Controller aus deiner Hardware sehen. Ich schreibe sowas nicht umsonst...

              Berni341 Aug 24 17:58:34 archlinux kernel: e1000e 0000:00:1f.6 eno1: renamed from eth0

              blödefrage, müsste das nicht enp1 und nicht eno1, bzw enp0s, für den ersten netzewerk?
              [ 2.408594] donar kernel: e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0

              @Berni341
              Du suchst die Datei nic-speed-fix.service in /etc/systemd/ (kann in network oder system oder user sein) und postest es hier.

              Was auch funktionieren sollte ist:
              systemctl cat nic-speed-fix.service
              Falls in dem Service bei ExecStart ein Skript gestartet wird dann dieses Skript ebenfalls posten.

              @brikler
              Diese "Umbenennung" von systemd paßt AFAIK, Nics mit Intel(e100xxx) Treiber heißen dann enoX.
              Die richtige Nic wird ja auch behandelt. Paßt also schon.
              //Edit: OK, du hast ja auch den Treiber... Kommt wohl auf den verwendeten Chipsatz an. Dürfte aber keine Ursache sein...

                GerBra
                systemctl cat nic-speed-fix.service:

                [Unit]
                Description=NIC speed fix service
                After=network.target
                
                [Service]
                Type=simple
                ExecStart=/usr/bin/ethtool -K eno1 tso off gso off
                Restart=on-failure
                
                [Install]
                WantedBy=multi-user.target

                Es ist richtig, 10MBit sind wegen der Leitung fix eingestellt. Sowohl der Rechner als auch der Router haben keine Ausweichmöglichkeit (nur mit grösseren Umständen) über eine andere, besser Leitung, die Geschwindigkeit wäre jedoch ausreichend, sollte aber nicht noch weniger werden.

                Bitte auch nochmal dein aktuelles Network-Manager Konfig für "Kabellose Verbindung" posten. Nutzt du eine statische IP oder eine per DHCP zugeteilte?

                Die IP für den Rechner wird vom Router fest zugeteilt. Wie lautet der Befehl der Network-Managerkonfig für die (nicht vorhandene) kabellose Verbindung (der Rechner hängt am Kabel am Router)?
                Die lspci -vv Ausgabe ist hier auf pastebin.
                (Nächstes Mal bei sowas wie curl -F 'file=@-' 0x0.st bitte vorwarnen, wenn das automatisch für ein ganzes Jahr ins Netz kommt, würde das gern selbst kontrollieren, was wo wie lange erscheint.)

                Hier ein aktuelles log, erstellt mit
                journalctl --boot 0 --unit NetworkManager --no-hostname --no-pager
                Man beachte die Zeit 16:04:33 und 16:07:02:

                Aug 27 16:04:21 systemd[1]: Starting Network Manager...
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.8829] NetworkManager (version 1.42.6-1) is starting... (boot:3cd81084-7576-4a55-9b96-ddf42fb4abb2)
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.8830] Read config: /etc/NetworkManager/NetworkManager.conf (lib: 20-connectivity.conf)
                Aug 27 16:04:21 systemd[1]: Started Network Manager.
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.8863] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.8935] manager[0x56303f3fb310]: monitoring kernel firmware directory '/lib/firmware'.
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.9722] hostname: hostname: using hostnamed
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.9722] hostname: static hostname changed from (none) to "archlinux"
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.9725] dns-mgr: init: dns=default,systemd-resolved rc-manager=symlink
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.9737] manager[0x56303f3fb310]: rfkill: Wi-Fi hardware radio set enabled
                Aug 27 16:04:21 NetworkManager[317]: <info>  [1693145061.9737] manager[0x56303f3fb310]: rfkill: WWAN hardware radio set enabled
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0015] Loaded device plugin: NMAtmManager (/usr/lib/NetworkManager/1.42.6-1/libnm-device-plugin-adsl.so)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0288] Loaded device plugin: NMTeamFactory (/usr/lib/NetworkManager/1.42.6-1/libnm-device-plugin-team.so)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0314] Loaded device plugin: NMOvsFactory (/usr/lib/NetworkManager/1.42.6-1/libnm-device-plugin-ovs.so)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0409] Loaded device plugin: NMWwanFactory (/usr/lib/NetworkManager/1.42.6-1/libnm-device-plugin-wwan.so)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0452] Loaded device plugin: NMWifiFactory (/usr/lib/NetworkManager/1.42.6-1/libnm-device-plugin-wifi.so)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0542] Loaded device plugin: NMBluezManager (/usr/lib/NetworkManager/1.42.6-1/libnm-device-plugin-bluetooth.so)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0545] manager: rfkill: Wi-Fi enabled by radio killswitch; enabled by state file
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0546] manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0546] manager: Networking is enabled by state file
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0552] settings: Loaded settings plugin: keyfile (internal)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0597] dhcp: init: Using DHCP client 'internal'
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0599] manager: (lo): new Loopback device (/org/freedesktop/NetworkManager/Devices/1)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0608] device (lo): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0612] device (lo): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0617] device (lo): Activation: starting connection 'lo' (a9f8a9f9-e6d9-407f-b287-ed2541d56259)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0625] manager: (eno1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.0627] device (eno1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2567] ovsdb: disconnected from ovsdb
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2574] device (lo): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2579] device (lo): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2583] device (lo): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2595] device (lo): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2630] device (lo): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2634] device (lo): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
                Aug 27 16:04:22 NetworkManager[317]: <info>  [1693145062.2643] device (lo): Activation: successful, device activated.
                Aug 27 16:04:28 NetworkManager[317]: <info>  [1693145068.2505] manager: startup complete
                Aug 27 16:04:33 NetworkManager[317]: <info>  [1693145073.5319] agent-manager: agent[51c800adb0033f78,:1.34/org.kde.plasma.networkmanagement/1000]: agent registered
                Aug 27 16:07:02 NetworkManager[317]: <info>  [1693145222.9516] device (eno1): carrier: link connected
                Aug 27 16:07:02 NetworkManager[317]: <info>  [1693145222.9521] device (eno1): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
                Aug 27 16:07:02 NetworkManager[317]: <info>  [1693145222.9535] policy: auto-activating connection 'Kabelgebundene Verbindung 1' (f26fb504-bd87-3b83-af2a-6a89ef8d623e)
                Aug 27 16:07:02 NetworkManager[317]: <info>  [1693145222.9544] device (eno1): Activation: starting connection 'Kabelgebundene Verbindung 1' (f26fb504-bd87-3b83-af2a-6a89ef8d623e)
                Aug 27 16:07:02 NetworkManager[317]: <info>  [1693145222.9546] device (eno1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
                Aug 27 16:07:02 NetworkManager[317]: <info>  [1693145222.9552] manager: NetworkManager state is now CONNECTING
                Aug 27 16:07:03 NetworkManager[317]: <info>  [1693145223.0488] device (eno1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
                Aug 27 16:07:03 NetworkManager[317]: <info>  [1693145223.0514] device (eno1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
                Aug 27 16:07:03 NetworkManager[317]: <info>  [1693145223.0537] dhcp4 (eno1): activation: beginning transaction (timeout in 45 seconds)
                Aug 27 16:07:05 NetworkManager[317]: <info>  [1693145225.3480] device (eno1): carrier: link connected

                Das Log zeigt wohl das bekannte Verhalten. eno1 wird vom Networkmanager/dbus zeitnah erkannt, hat aber carrier Probleme. Nach ~ 3min klappt der Carrier dann.

                Dein nic-speed Service: Hier stellst du ja nur das Fragmentieren von TCP und anderen Paketen ab, was bei langsamen Verbindungen ggf. einen Vorteil bringt. Die Geschwindigkeit setzt du aber nicht.

                Vorschlag: Versuche es mal mit einem eigenen Netzwerk-Setup-Skript anstatt NetworkManager.
                Dazu stellst du den NM-Service ab:
                systemctl disable NetworkManager
                //Edit: deinen nic-speed Service auch abschalten:
                systemctl disable nic-speed-fix
                Nach einem Reboot hast du dann kein Netzwerk, der Befehl:
                ip link show dev eno1
                sollte state DOWN anzeigen.

                Einschalten kannst du den NM (wenn nötig) wieder mit:

                systemctl enable NetworkManager
                systemctl enable nic-speed-fix
                reboot

                Ich habe auf die Schnelle mal das zusammengezimmert:

                #!/usr/bin/sh
                
                DEV=eno1
                
                echo "Start"
                date +%X
                #
                echo "UP"
                date +%X
                ip link set $DEV up
                #
                echo "Speed"
                date +%X
                # ethtool -s $DEV advertise 0x002 autoneg on
                ethtool -s $DEV speed 10 duplex full autoneg off
                ethtool -K $DEV tso off gso off
                #
                echo "Get IP"
                date +%X
                dhcpcd $DEV
                #
                echo "Ping"
                date +%X
                ping -c 5 8.8.8.8
                ping -c 1 google.de

                Das Skript speicherst du z.B. unter /usr/local/bin/nic-up.sh
                Starten kannst du es als root oder per sudo:

                sh /usr/local/bin/nic-up.sh
                sudo sh /usr/local/bin/nic-up.sh

                Das Skript setzt die Nic UP, stellt per ethtool (hoffentlich!) eine 10baseT/FULL Verbindung ein und bezieht dann per dhcp die IP-Adresse. Versucht dann 5 Pings an einen Google-Nameserver und einen (wegen der DNS-Namensauflösung) direkt zu google.de.
                Zwischendrin sind ein paar echo's und Zeitausgaben eingestreut um ggf. Zeitprobleme zu erkennen.

                Poste doch bitte dann mal:
                a) die komplette Ausgabe des Skripts
                b) journalctl -S HH:MM --no-hostname --no-pager
                (Für HH:MM setzt du die erste Zeit ein, die das Skript dir anzeigt)
                Das ist dann ein kleiner Journal-Auszug, den kannst du sicher hier einstellen.

                Es kann sein, daß der letzte Ping nach google.de einen Fehler wirft, dann klappt die Namensauflösung nicht aufgrund dem, wie NM diese handhabt. Das kann aber leicht geändert werden.

                Falls die Namensauflösung funktioniert, dann kannst du ja mal eine Zeitlang unter der Konstellation testen, ob es bzgl. der Probleme (Geschwindigkeit, evtl. Abbrüche) beim "normalen Browsen, Netzwerken" einen Unterschied gibt.

                Ziel des ganzen wäre:
                a) Gibt es damit auch Verzögerungen beim Aufbau des Links und/oder IP-Bezug?
                b) Es ist ein zusammenhängender Vorgang, der sich ggf. leichter diagnostizieren läßt.
                c) Sorgt diese händische Methode ggf. für eine stabilere Verbindung bzgl. deiner "Gegebenheiten"

                Evtl. wäre das eine Grundlage für einen eigenen Service (davon ist das Skript momentan weit entfernt), dann könntest du auf NM o.ä. verzichten.
                Momentan - wenn du etwas ändern wolltest - bedarf es eines Reboots und erneuten Starten des Skripts.

                Bei groben Problemen helfe ich dir gerne jetzt noch weiter, ich hoffe keine Fehler ins Skript eingebaut zu haben (nur in einer virtuellen Maschine getestet).

                • Berni341 hat auf diesen Beitrag geantwortet.

                  GerBra
                  Danke erstmal für die Hilfe. Ich werde wohl etwas Zeit benötigen, das alles entsprechend einzustellen und auszutesten. Habe ich Resultate, melde ich mich wieder.

                  GerBra
                  Was soll ich sagen? Das Script läuft, die Verbindung ist in 1-2 Sekunden da ☺️. Hier die Ausgabe von
                  sudo sh /usr/local/bin/nic-up.sh:

                  Start
                  21:16:36
                  UP
                  21:16:36
                  Speed
                  21:16:36
                  Get IP
                  21:16:36
                  dhcpcd-10.0.2 starting
                  DUID 00:01:00:01:2c:7b:34:18:10:e7:c6:00:ed:0b
                  eno1: waiting for carrier
                  eno1: carrier acquired
                  eno1: IAID c6:00:ed:0b
                  eno1: adding address fe80::a1cd:b41b:1565:3609
                  eno1: soliciting an IPv6 router
                  eno1: rebinding lease of 192.168.178.35
                  eno1: probing address 192.168.178.35/24
                  eno1: leased 192.168.178.35 for 864000 seconds
                  eno1: adding route to 192.168.178.0/24
                  eno1: adding default route via 192.168.178.1
                  forked to background, child pid 1367
                  Ping
                  21:16:44
                  PING 8.8.8.8 (8.8.8.8) 56(84) Bytes an Daten.
                  64 Bytes von 8.8.8.8: icmp_seq=1 ttl=116 Zeit=21.3 ms
                  64 Bytes von 8.8.8.8: icmp_seq=2 ttl=116 Zeit=19.7 ms
                  64 Bytes von 8.8.8.8: icmp_seq=3 ttl=116 Zeit=19.9 ms
                  64 Bytes von 8.8.8.8: icmp_seq=4 ttl=116 Zeit=19.7 ms
                  64 Bytes von 8.8.8.8: icmp_seq=5 ttl=116 Zeit=19.7 ms
                  
                  --- 8.8.8.8 ping-Statistik ---
                  5 Pakete übertragen, 5 empfangen, 0% packet loss, time 4007ms
                  rtt min/avg/max/mdev = 19.697/20.070/21.284/0.612 ms
                  PING google.de (142.250.186.67) 56(84) Bytes an Daten.
                  64 Bytes von fra24s05-in-f3.1e100.net (142.250.186.67): icmp_seq=1 ttl=57 Zeit=19.6 ms
                  
                  --- google.de ping-Statistik ---
                  1 Pakete übertragen, 1 empfangen, 0% packet loss, time 0ms
                  rtt min/avg/max/mdev = 19.576/19.576/19.576/0.000 ms

                  Ein Icon in der Taskbar wäre auch nicht schlecht. Leider funktioniert das hier nicht und bricht bei Installation mit einer Fehlermeldung ab (wird auch von anderen Nutzern auf der Seite hingewiesen). Gibt es eine Alternative dazu?

                  Das Problem kann als gelöst betrachtet werden. Aufgrund des sehr gut funktionierenden Scripts von GerBra war es mir möglich, den Fehler zu lokalisieren, in dem nacheinander der ein oder andere Befehl im Script weggelassen und die Funktion geprüft wurde. Am Ende stellte sich heraus, dass die Eingabe des Befehles ethtool -s eno1 speed 10 duplex full autoneg off für eine sofortige Netzwerverbindung sorgt. Diesen habe ich dann als systemd-service-Datei unter etc/systems/system angelegt. Und so sieht er aus:

                  [Unit]
                  Description=ethtool configuration to enable 10mbps speed for the specified adapter
                  After=network-online.target
                  Wants=network-online.target
                  
                  [Service]
                  ExecStart=/usr/bin/ethtool -s eno1 speed 10 duplex full autoneg off
                  Type=oneshot
                  
                  [Install]
                  WantedBy=multi-user.target

                  Danach noch sudo systemctl enable [name]@[servicename].service und schon verbindet sich nach Boot das Netzwerk unverzüglich beim Laden des Desktops.
                  Bleibt nur die Frage, warum dafür ein Extra-Service notwendig ist, wenn genau die gleichen Angaben bereits im NetworkManager und auch im NetworkManager-Connection-Editor eingegeben sind.
                  Ich bedanke mich für die Hilfe im allgemeinen und bei GerBra im speziellen für das Script, ohne das sich die Suche wohl noch weiter hingezogen hätte.
                  PS: Ich werde den Strang mit überflüssigen log-Angaben meinerseits aufräumen, damit bei evtl. späterem Nachlesen möglichst keine Verwirrung auftritt.

                  • GerBra hat auf diesen Beitrag geantwortet.

                    Freut mich, das es nun zufriedenstellend funktioniert, ich hatte eher nicht damit gerechnet...

                    Berni341 Bleibt nur die Frage, warum dafür ein Extra-Service notwendig ist, wenn genau die gleichen Angaben bereits im NetworkManager und auch im NetworkManager-Connection-Editor eingegeben sind.

                    Evtl. funktioniert dieser Teil im NM nicht richtig, eine Verbindung zu drosseln auf Client-Seite ist ja auch eher "unüblich" im "Normalbetrieb" (wobei das ja ggf. bei Fibre->Kupfer wieder eine Rolle spielen kann). Ich kenne NM nicht sehr intensiv, aber ich glaube das man diesen auch zum Debugging zwingen kann mit dann erheblichen Ausgabenmengen.
                    Aber eigentlich ist ja der NM für eine feste Kabelverbindung ja auch eher Overkill, das Handling/Feeling ist halt das was User heute gewöhnt sind.

                    Zum Skript bzw. dem Runterdrosseln mit ethtool: Ich war mir unsicher, ob das UP-Setzen des Devices mit ip am Besten vor oder nach ethtool passieren soll. Gerade weil die Ursache IMHO ja im Carrier-Bereich zu liegen schien. Momentan kannst du wahrscheinlich froh sein, daß der NM die Einstellungen von ethtool nicht einfach wieder "resettet" ;-)

                    Einen Gefallen könntest du mir noch mal tun, aus Interesse meinerseits:
                    Im Skript habe ich eine auskommentierte Zeile um ggf. auf eine andere Art eine 10baseT/Full Verbindung herzustellen, nämlich:
                    ethtool -s $DEV advertise 0x002 autoneg on
                    Da ja jetzt sicher ist, daß ethtool mit dem anderen Befehl die Ursache beseitigt würde ich ich bitten, diese Zeile z.B. in deinem Service oder im Skript mal alternativ zu testen.
                    Diese Optionen veranlassen, daß Nic<->Switch die Geschwindigkeit wieder untereinander aushandeln (Autonegotation), die Nic bietet dabei aber nur 10baseT/Full (0x002) an.
                    Würde mich interessieren, ob das bei deinen "Zuständen"<g> ebenfalls funktioniert.

                    War für dich mit Sicherheit auch hilfreich/interessant etwas über Logfiles, Netzwerk-Tools etc. kennen und verstehen zu lernen, die nächsten (Netzwerk)probleme sind dann meist einfacher zu handhaben mit mehr Wissen über die Abläufe.

                    //Edit: du kannst auch mittels ethtool -S mal nach einiger Zeit nachprüfen, ob deine weiter oben festgestellten Empfangs-Checksummen-Fehler immer noch so hoch sind, bei einer sauberen Verkabelung/Verbindung sollte bei keinem der *_errors etwas anderes als Null stehen.

                    • Berni341 hat auf diesen Beitrag geantwortet.

                      GerBra

                      //Edit: du kannst auch mittels ethtool -S mal nach einiger Zeit nachprüfen, ob deine weiter oben festgestellten Empfangs-Checksummen-Fehler immer noch so hoch sind, bei einer sauberen Verkabelung/Verbindung sollte bei keinem der *_errors etwas anderes als Null stehen.

                      Die Errors sind immer noch da, auch in der Anzahl kaum verändert. Hier macht sich die Qualität der Leitung bemerkbar. Was das betrifft:

                      ethtool -s $DEV advertise 0x002 autoneg on

                      Hier zeigt sich auch ganz klar die schlechte Leitungsqualität, die Verbindung baut sich auf und bricht nach unterschiedlich kurzen Zeiträumen von wenigen bis einigen mehr Sekunden zusammen, um sich danach wieder neu aufzubauen und danach wieder der Abbruch usw. usf. Das heisst, die Autonegotiation versucht wohl auf 100MBit-Basis die Leitung zu etablieren, erkennt aber nicht, das 10MBit hier angemessener wäre. Das gleiche Verhalten zeigt sich übrigens auch unter Windows11. Der Router selbst hängt an einer Leitung mit 16MBit und liefert die Daten wohl schneller als 10MBit weiter und vermutlich ist das auch das Erkennungssignal für den NIC/Autonegotiation und weniger die Leitungsqualität. Wenn man die Leitung jemand zeigen würde (und die zwischen 2 Leitungsabschnitten auch noch vorhandene Lüsterklemme(!!!) in einer Wanddose), gäbe es vermutlich zunächst ein Schmunzeln und danach ein Staunen, dass überhaupt etwas durchkommt. Aber, wie gesagt, für den Zweck dieses Rechners sind die 10MBit ausreichend, da werden keine HD-Videos gestreamt oder Gaming betrieben, daher sollte es nur stabil laufen und schnell connecten.