Ich sehe da keine Fehler, wenn ich das nicht falsch lese braucht deine Netzwerkkarte nach dem Start aber ca 90 sec bis sie aktiv ist. Allerdings stellt sich mir die Frage, wozu du bei ner kabelgebundenen Verbindung den NetworkManager brauchst. Und den rfkill-service hattest du nicht wie von Stefan empfohlen deaktiviert, oder?

Danke fürs Drübergucken. Die Daten sind natürlich alle ohne Fehlerbehandlung ausgelesen. Den Networkmanager habe ich für KDE (siehe erster Post). Jetzt kann es dann daran gehen, in der Hoffnung, es ändert sich was. Falls noch jemand Vorschläge hat, bitte reinschreiben.

Wenn ich sudo systemctl disable systemd-rfkill.service ausführen will, bekomme ich das:

The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Ich starte meine Netzwerkverbindung unter Plasma/KDE mit systemct start dhcpcd@enp5s0.service, ohne Networkmanager. Bei dir wäre das wohl dhcpcd@eno1.service, Sicherheit gibt ein Blick auf die Ausgabe von ip link. Du müsstest dann aber den NetworkManager.service deaktivieren.
Eventuell erledigt sich dann auch das Starten von rfkill

Werde ich ausprobieren. Was ich auch überhaupt nicht verstehe, ist diese Unregelmässigkeit der Zeit bis zur Netzwerkaktivität. Mal ist das Netzwerk direkt nach Boot da (selten), wie es sein sollte und mal sitzt man da und wartet ca. 3 bis 4 Minuten, bis sich etwas tut. Und alles zeitlich dazwischen ist auch möglich.

edit: Mit dhcpcd genau dasselbe. Zunächst NetworkManager deaktiviert, dhcpcd aktiviert ("enable" und "start"), beim Neustart dann Wartezeit bis Timeout - danach kein Netzwerk. Habe dann nicht mehr abgewartet, ob es sich nach einer gewissen Zeit wieder selbst aktiviert.

edit2: vielleicht ist das noch interressant, nach Re-Aktivierung von Networkmanager wirft nmcli folgendes aus:
Netzwerk nicht aktiv:
NetworkManager is running
Nach ca. 2 Minuten warten - ab hier wird Netzwerkverbindung aufgebaut:

eno1: nicht verbunden
eno1: Verbindung »Kabelgebundene Verbindung 1« wird verwendet
eno1: wird verbunden (wird vorbereitet)
NetworkManager ist jetzt im Zustand »wird verbunden«
eno1: wird verbunden (wird eingerichtet)
eno1: wird verbunden (IP-Einstellungen werden ermittelt)
»Kabelgebundene Verbindung 1« ist jetzt die primäre Verbindung
eno1: wird verbunden (IP-Funktionalität wird geprüft)
eno1: wird verbunden (Zweitverbindungen werden gestartet)
eno1: verbunden
NetworkManager ist jetzt im Zustand »verbunden (nur Gelände)«
Verbindungszustand ist jetzt »begrenzt«
NetworkManager ist jetzt im Zustand »verbunden«
Verbindungszustand ist jetzt »vollständig«

Hier ist mir eine Diskrepanz aufgefallen. Erst wenn nach Wartezeit die Verbindung aufgebaut wird, erscheint die Meldung "eno1: nicht verbunden", zuvor ist nur "NetworkManager is running" zu sehen. Es scheint, als ob ein (anderer?) Service/Prozess diese Zeit braucht, bevor die Netzwerkverbindung steht. Sonst stünde doch das "eno1: nicht verbunden" schon von Anfang an da und nicht erst ab dem Zeitpunkt, ab dem die Verbindung aktiv wird. Vielleicht ist das alles aber auch nur Kaffeesatzleserei.

Ohne konkret zum Problem beitragen zu wollen:

Am interessantesten wäre wohl ein Logfile von einem Zustand in dem das "Aktivieren" des Netzwerks extrem lange ("mal sitzt man da und wartet ca. 3 bis 4 Minuten") dauerte. Am besten - wenn das wieder mal auftritt - merkst du dir Tag/Uhrzeit. Wenn du dann neu bootest kommst du an das komplette Journal für den vorherigen Boot(mit dem Problem) mittels:
journalctl --system --boot -1
(oder -2, -3 noch weiter zurück). Eine Liste der letzten Bootvorgänge bekommst du mit:
journalctl --list-boots
(ggf. sudo verwenden für die Kommandos falls nicht als root unterwegs)

Du hast gesehen welchen Aufwand es bedarf ein Journal zu posten. Außerdem fehlen bei dir Teile (an den "Enden" der Zeilen, da du aus dem sog. Pager rauskopiert hast.
Einfacher geht das mittels eines sog. Pastebin-Services, siehe im Wiki:
https://wiki.archlinux.org/title/List_of_applications#Pastebin_services
Auch lange/komplexe Programmausgaben lassen sich so einfacher für alle handhaben.
Um z.B. das komplette Journal vom letzten Boot zur Verfügung zu stellen:
journalctl --system -b -1 | curl -F 'file=@-' 0x0.st
(//Edit: Das Tool/Paket curl muß evtl. nachinstalliert werden falls nicht vorhanden)
Du erhältst dann eine URL, die du dann in deinem Post reinstellen kannst nebst ggf. anderen Infos. Keine Notwendigkeit, überlange Texte mühsam zu kopieren.

Nachtrag zum ersten Post deinerseits:
Diese "lange Wartespanne": bezieht die sich auf das "visuelle Bereitmelden" vom Networkmanager-Applet? Schonal getestet (ping z.B.) ob die Verbindung nicht doch schon während dieser "visuellen Problemphase" aktiv ist?

Ggf. auch interessant (obwohl schon mal angesprochen): konkurrierende Dienste. Was sagt:
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

  • Berni341 hat auf diesen Beitrag geantwortet.

    GerBra
    Danke für die Tipps, werde sie nutzen.
    Die Wartespanne bis zur vorhandenen, aktiven Verbindung ist kein visueller Fehler, die Verbindung ist tatsächlich so lange nicht da, wie sie auch als visuell "nicht verfügbar" gekennzeichnet ist. Das habe ich bereits mehrfach getestet.
    Der Aufruf von...
    find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
    ... führt zu:

    cups.path                                | multi-user.target.wants
    cups.service                             | multi-user.target.wants
    cups.service                             | printer.target.wants
    cups.socket                              | sockets.target.wants
    dbus-org.freedesktop.nm-dispatcher.service | system
    dbus-org.freedesktop.timesync1.service   | system
    display-manager.service                  | system
    fstrim.timer                             | timers.target.wants
    gcr-ssh-agent.socket                     | sockets.target.wants
    getty@tty1.service                       | getty.target.wants
    gnome-keyring-daemon.socket              | sockets.target.wants
    NetworkManager.service                   | multi-user.target.wants
    NetworkManager-wait-online.service       | network-online.target.wants
    nic-speed-fix.service                    | multi-user.target.wants
    p11-kit-server.socket                    | sockets.target.wants
    pipewire-pulse.socket                    | sockets.target.wants
    pipewire-session-manager.service         | user
    pipewire.socket                          | sockets.target.wants
    remote-fs.target                         | multi-user.target.wants
    systemd-timesyncd.service                | sysinit.target.wants
    wireplumber.service                      | pipewire.service.wants
    xdg-user-dirs-update.service             | default.target.wants

    Gut, also - wie du weiter oben schon mal angeführt hast - es gibt keine konkurrierenden Netzwerk-Dienste.

    Wir bräuchten aber wirklich ein komplettes Journal von einem Boot bei dem das Problem "mit erheblicher Verzögerung" aufgetreten ist. Am besten also wie von mir ausgeführt warten bis das Problem auftritt, rebooten, und dann das letzte Journal (b -1) per pastebin ablegen.
    Diese Verzögerung sollte - sofern Netwokmanager ggf. die Ursache wäre - im Log ersichtlich sein, hoffentlich mit hilfeführenden Meldungen oder Kontext.

    Zum "Rumtesten" haben dir ja andere auch schon zu einem anderen Netzwerk-Manager geraten, das wäre sicher eine Möglichkeit, gerade wenn es sich um eine feste, stationäre Ethernet-Verbindung dreht. Ich sehe allerdings bisher keinen Grund, warum Network-Manager das nicht (auch) fehlerfrei können müßte.

    Als anderen Test (mit dem gleichen momentanen Setup) wäre auch möglich, den LTS-Kernel parallel zum Standard-Kernel zu installieren und mit diesem eine Zeitlang zu testen ob das Problem da auch auftritt.

    Ich hab mal die von dir geposteten Journalteile überflogen, das war aber ja wohl von einem Lauf ohne das Problem. Was mir darin aufgefallen ist bzw. Fragen dazu:

    a) Nutzt du aktiv eine Firewall auf dem PC?
    "Aug 24 17:58:48 archlinux firewall-applet[814]: Traceback (most recent call last):"
    Kannst du dieses Applet mal deaktivieren und prüfen ob sich am Verhalten bzgl. Netzwerk-Zugriffszeit was ändert?

    b) Poste bitte mal die Ausgabe von:
    pacman -Qs xdg-desktop-portal

    Und zur Sicherheit:
    Das Paket linux-firmware ist installiert?
    Verwendest du irgendwelche "Sicherheitskonzepte" wie MAC-Changer, am Router nur bestimmte MAC-Adressen zugelassen o.ä. ?
    Ist auf dem Rechner auch ein Windows installiert?

    • Berni341 hat auf diesen Beitrag geantwortet.

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