plasma widget für netzwerverbindung

Started by unklarer, 2026/10/25, 09:21:53

Previous topic - Next topic

unklarer

Hallo Gemeinde,

In der neuen Big Crime zeigt mir das Widget nach dem Hochfahren des Laptop die wlan-Verbindung mit "Verbunden" an.
In der Konsole scheitert das Update, weil die Sources nicht aufgelöst werden können.

Trenne ich im Widget die "Verbindung" und verbinde anschließend neu, hat auch die Konsole keine Probleme mehr.

Wo ist 'dran zu drehen, dass das wirklich klappt?

hendrikL

Ich hatte ein ähnliches Problem, eigentlich das selbe.

Nicht mit Big_Crime, sondern einer älteren, aber aktuellen Installation.
Bei meinem System stellte sich IPv6 als Bremser heraus.

Du kannst nach einem Neustart mal schauen, ob es daran hängt.

journalctl -o short-monotonic -b -0 | grep -i 'wlan'

Oder halt das kabelgebundene, wenn kein WLAN.

Ich habe in der /etc/iwd/main.conf Folgendes angefügt bzw. das Kommentarzeichen entfernt: EnableIPv6=false

cat /etc/iwd/main.conf

# For complete description of supported configuration options, refer to
# 'man 5 iwd.config'.

[General]
# iwd is capable of performing network configuration on its own, including
# DHCPv4 based address configuration.  By default this behavior is
# disabled, and an external service such as NetworkManager, systemd-network
# or dhcpclient is required.  Uncomment the following line if you want iwd
# to manage network interface configuration.
#
#EnableNetworkConfiguration=true
#
# iwd can randomize your WiFi card's MAC address for additional privacy.  By
# default, this behavior is disabled and the MAC address assigned by the
# kernel driver is used.  The address will be stable when connecting
# to a saved network profile, so as to not interfere with any MAC filtering
# rules that exist on the network.
# If a randomized MAC address is desired, uncomment the setting line below:
#
#AddressRandomization=network
#
# Options below control the roaming thresholds on 2.4 & 5G bands.
# Normally the default values are a good compromise that avoids excessive
# scanning while maintaining good link quality.
#
#RoamThreshold=-70
#RoamThreshold5G=-76
#
[Network]
# If EnableNetworkConfiguration=true is set, iwd forwards DNS information to
# the system resolving service.  The currently supported services are:
# - systemd-resolved ["systemd"]
# - openresolv / resolvconf ["resolvconf"]
# - none
#
# If not set, the value "systemd" is used by default.  Uncomment the value
# below if you are using openresolv:
#
#NameResolvingService=resolvconf
#
# iwd's support for IPv6 should be stable enough and is now enabled by default.
# If you experience any problems and want to force IPv6 to be disabled,
# uncomment the setting below:

EnableIPv6=false




unklarer

Danke, hendrikL, das ist es nicht.

Quotejournalctl -o short-monotonic -b -0 | grep -i 'wlan'
[  20.356416] localhost iwd[735]: udev interface=wlan0 ifindex=4
[  23.031688] localhost.localdomain NetworkManager[858]: <info>  [1793019905.0016] manager: (wlan0): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/3)
[  23.031925] localhost.localdomain NetworkManager[858]: <info>  [1793019905.0018] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
[  23.044881] localhost.localdomain NetworkManager[858]: <info>  [1793019905.0148] device (wlan0): new IWD device state is disconnected
[  23.046981] localhost.localdomain NetworkManager[858]: <info>  [1793019905.0169] device (wlan0): state change: unavailable -> disconnected (reason 'supplicant-available', managed-type: 'full')

und die main.conf
Quote[General]
EnableNetworkConfiguration=true

[Network]
NameResolvingService=systemd

schließlich habe ich mit nmtui in der 'Bearbeitung' der wlan-Schnittstelle festgestellt, dass das Gerät "wlan0" und "automatisch Verbinden" nicht eingetragen waren.
Seitdem das gemacht ist, ist der Fehler nicht mehr aufgetaucht. Mal gucken, wie lang...


unklarer

Nun, zuverlässig funktioniert das trotzdem nicht.  😕
Nachdem jetzt der neue kernel installiert ist, tritt es wieder auf. Dabei sind die Einstellungen laut nmtui nicht verloren gegangen, sondern immer noch korrekt.

KDE war schon früher 🤐  für mich die 'lahmste Ente' aller Desktops. Ich hatte da so meine Probleme mit dem Timing von conky. 😢
Es ist immer noch so!  Beispiel nachvollziehbar getestet. Egal ob Kaltstart oder Warmstart



Das plasma-widget rechts erscheint sofort. 2 Sec. später, wie eingestellt, der conky links. Und, die Leiste läßt sich Zeit(man reibt sich die Augen) mindestens 5 Sec.

Das Problem erscheint mir also daran zu liegen. Ich weiß jedoch jetzt nicht, wo das Netzwerk so lange zu verzögern ist, bis diese Leiste hochgekommen ist.

der_bud

Du könntest Dir mal diese Beiden:
systemd-analyze blame
systemd-analyze critical-chain
auf Auffälligkeiten ansehen. Sollte dabei der Start von
irgendwasmitNetz-wait-online.service auftauchen, das mal disablen.
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

unklarer

@der_bud, keine Auffälligkeiten. Gesamte Ausgabe aus einer Datei:
8.425s dev-sdb2.device
7.029s e2scrub_reap.service
6.254s accounts-daemon.service
5.932s udisks2.service
5.779s grub2-common.service
4.724s fwupd-refresh.service
4.451s polkit.service
4.274s apt-daily.service
4.249s fwupd.service
4.120s avahi-daemon.service
4.106s bluetooth.service
4.093s dbus.service
3.884s iwd.service
3.859s switcheroo-control.service
3.519s smartmontools.service
3.119s NetworkManager.service
2.825s systemd-udevd.service
2.745s upower.service
2.525s systemd-tmpfiles-setup-dev-early.service
2.489s cups.service
2.465s systemd-journal-flush.service
2.187s lvm2-monitor.service
2.073s exim4.service
1.549s gpm.service
1.501s ModemManager.service
 808ms systemd-random-seed.service
 714ms systemd-timesyncd.service
 669ms systemd-udev-trigger.service
 643ms systemd-sysctl.service
 518ms systemd-modules-load.service
 515ms systemd-logind.service
 486ms run-rpc_pipefs.mount
 465ms lm-sensors.service
 457ms user@1000.service
 417ms systemd-journald.service
 407ms dev-hugepages.mount
 406ms dev-mqueue.mount
 406ms sys-kernel-debug.mount
 405ms sys-kernel-tracing.mount
 396ms rpc-statd-notify.service
 377ms keyboard-setup.service
 377ms kmod-static-nodes.service
 370ms modprobe@configfs.service
 369ms modprobe@fuse.service
 365ms systemd-udev-load-credentials.service
 353ms systemd-hostnamed.service
 343ms systemd-fsck@dev-disk-by\x2duuid-0EE1\x2dBA9D.service
 329ms xfs_healer_start.service
 324ms systemd-remount-fs.service
 282ms systemd-tmpfiles-setup.service
 240ms systemd-rfkill.service
 219ms boot-efi.mount
 216ms alsa-restore.service
 171ms blk-availability.service
 161ms systemd-userdbd.service
 152ms systemd-backlight@backlight:intel_backlight.service
 144ms systemd-tmpfiles-clean.service
 127ms rpcbind.service
 108ms dev-disk-by\x2duuid-c2a19a6f\x2dd5cf\x2d46b3\x2dbcbd\x2d21c1647c5dde.swap
 105ms pcscd.socket
  96ms systemd-binfmt.service
  94ms console-setup.service
  90ms systemd-user-sessions.service
  81ms sshd-unix-local.socket
  78ms power-profiles-daemon.service
  72ms rtkit-daemon.service
  63ms systemd-journalctl.socket
  51ms systemd-userdb-load-credentials.service
  45ms openvpn.service
  44ms proc-sys-fs-binfmt_misc.mount
  36ms systemd-coredump.socket
  30ms sys-fs-fuse-connections.mount
  29ms sys-kernel-config.mount
  24ms user-runtime-dir@1000.service
  21ms systemd-tmpfiles-setup-dev.service
  19ms tmp.mount
  18ms polkit-agent-helper.socket
  6ms systemd-ask-password.socket
  6ms systemd-creds.socket
  3ms rpcbind.socket
  1ms systemd-sysext.socket
 826us systemd-mute-console.socket
 791us systemd-sysupdate.socket
 722us systemd-storage-fs.socket
 703us systemd-storage-block.socket
 676us systemd-factory-reset.socket
 623us systemd-cryptenroll.socket
 559us systemd-sysinstall.socket
  93us systemd-machined.socket
  88us dbus.socket
  86us systemd-udevd-varlink.socket
  84us avahi-daemon.socket
  83us systemd-importd.socket
  82us systemd-logind-varlink.socket
  79us cups.socket
  74us systemd-journald-dev-log.socket
  64us systemd-journald.socket
  58us systemd-userdbd.socket
  54us systemd-hostnamed.socket
  53us lvm2-lvmpolld.socket
  44us dm-event.socket
  22us systemd-udevd-kernel.socket
  13us systemd-rfkill.socket


The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @23.533s
└─power-profiles-daemon.service @23.453s +78ms
  └─multi-user.target @23.442s
    └─cups-browsed.service @23.441s
      └─cups.service @20.947s +2.489s
        └─network.target @20.928s
          └─NetworkManager.service @17.807s +3.119s
            └─dbus.service @13.711s +4.093s
              └─basic.target @13.688s
                └─sockets.target @13.687s
                  └─pcscd.socket @13.580s +105ms
                    └─sysinit.target @13.558s
                      └─haveged.service @13.524s
                        └─systemd-tmpfiles-setup.service @13.206s +282ms
                          └─local-fs.target @13.170s
                            └─boot-efi.mount @11.781s +219ms
                              └─systemd-fsck@dev-disk-by\x2duuid-0EE1\x2dBA9D.service @11.413s +343ms
                                └─dev-disk-by\x2duuid-0EE1\x2dBA9D.device @11.411s

Habe vor deinem Beitrag (danke dafür  😉  ) einen Ratschlag aus dem ubuntu-wiki verwirklicht, bei zu vielen FritzBoxen (und bei mir sind es viele) in dem plasma-nm-widget unter "Erweitert>Auf BSSID beschränken" diese zusätzlich eingetragen.

Erster Neustart ist OK. Abwarten und Tee trinken...