Arch Linux

Networkmanager - immer noch schlechter?

GerBra

Hallo,

gegeben ein Laptop der per (KDE)-Networkmanager(-Applet) eine Verbindung zum AP herstellt und einen Stream von ca. 300KB empfängt.

Per Networkmanager habe ich reproduzierbar Aussetzter, entweder bemerkbar durch Stocken des Bildes und Wiederaufnahme, meist aber nach 1,2 Stockungen erfolgt dann ein Re-Authentifizieren am AP (Disconnet, Reason 7).

Stoppe ich hingegen den Networkmanager und baue die Verbindung anschließend sofort per netcfg oder direkt per wpa_supplicant auf, dann gibt es (gleicher Treiber, gleicher Laptop, gleicher Standort, gleicher Stream) keinerlei Aussetzer/Disconnects mehr.

Ich sehe, daß mit dem Service networkmanager (ist eine systemd Umgebung, wobei das mal keine Rolle spielt <g>) auch ein wpa_supplicant-Prozeß gestartet wird, aber Networkmanager nutzt diesen ja scheinbar nicht - bzw. wenn dann anders. Ist der Qualitäts-/Stabilitätsunterschied zwischen NM und wpa_supplicant wirklich immer noch so groß? Scheinbar. Gibt es im NM irgendwelche Stellschrauben an denen ich drehen könnte? An dem Laptop sollte schon NM genutzt werden, aber wenn das nicht stabil ist…
Wikis und Suchmaschine haben mir zumindest nichts verwertbares beschert.

//Edit: Die IPv6-Geschichte habe ich schon durch…

Dirk

Hast du mal versucht, bei Problemen mit der Networkmanagerverbindung diese zu trennen, und wieder zu verbinden, anstatt netcfg zu benutzen (was spricht eigentlich gegen netcfg direkt?), um auszuschließen, ob es vielleicht ein Problem ist, dass sich durch Trennen und Neuverbinden (egal, womit) löst?

GerBra

Dirk Sohler schriebHast du mal versucht, bei Problemen mit der Networkmanagerverbindung diese zu trennen, und wieder zu verbinden,

Macht das Dings ja selbst (Disconnect = Reconnect mit allem Drumherum(dhcp usw.) ). Aber halt so alle 3-10 Minuten ;-)
Passiert auch (was ich bisher getestet habe) nur unter "dauerlast", d.h. ich habe per cron mal so alle 5Min eine Webseite per wget geholt, da gibt es keine Abbrüche ("Surfverhalten"). Aber eben sofort+dauerhaft wenn ein größerer Transfer stattfindet. Und dieses passiert ebe nur mit NM.

Andere Manager wären für den Zweck keine wirkliche Alternative, ich finde unter KDE das Applet schon recht gelungen und brauchbar. Außerdem sollen auch andere Möglichkeiten vom NM genutzt werden. Und nein - es ist nicht für mich <g> (Ich weiß schon, warum ich die Kombination wpa_supplicant+wpa_gui nutze <g>).

Xukashi

huhu, ich glaube das problem liegt eher an der kombination KDE+NM, ich hatte z.b. in der kombination laufend verbindungsabbrueche mit umts. unter gnome3 was ich jetzt gerade fahre hab ich diese probleme nicht.

GerBra

Hmm, aber es passiert ja auch ohne das Plasma-Äpp. Aktuelle NM (ggf. nur in Verbindung mit systemd) brauchen ja keinen Keyring o.ä. mehr, d.h. ich habe nach dem Boot direkt eine Verbindung zum AP. Es ist nur der KDM gestartet, kein User eingeloggt.

Jetzt kopiere ich (all das spielt sich im LAN ab, kein Trasfer über Internet) per rsync so 15 Files á rund 20MB nur auf der (TTY)Shell - und schwupps habe ich wieder den Disconnect. Das gleiche mit netcfg - no problemo…

Diese Prozesse laufen (kein KDE, nur KDM):

# ps ax | grep  -i -e network -e wpa
  386 ?        Ssl    0:00 /usr/sbin/NetworkManager --no-daemon
  457 ?        Ss     0:00 /usr/sbin//wpa_supplicant -u
  471 ?        S      0:00 /sbin/dhcpcd -B -K -L -G -c /usr/lib/networkmanager/nm-dhcp-client.action wlan0

Das NM hier wpa_supplicant nutzt wunderte mich halt (war früher IMHO nicht so), aber es ändert nichts - nur mit dem "Original" funktioniert es.

Hat den Anschein als vertrage NM die Arbeit nicht: "Huch, jetzt kommt aber viel Transfer - da mach ich doch mal Pause".
Erinnert mich an: "Ich putz die erste Hälfte der 1. Platte, ich verschauf ein wenig, dann putz ich die 2. Hälfte der ersten Platte. ich verschnauf ein wenig, dann putz ich die erste Hälfte der 2. Platte, ich verschnauf…"

Das es also was mit den Frontends/Äpps zu tun hat bezweifele ich irgendwie.

Log/dmesg (MAC-Addr verkürzt):

...
[   25.269034] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9
[   32.500868] wlan0: authenticate with 87:a8
[   32.503751] wlan0: send auth to 87:a8 (try 1/3)
[   32.505585] wlan0: authenticated
[   32.510039] wlan0: associate with 87:a8 (try 1/3)
[   32.513056] wlan0: RX AssocResp from 87:a8 (capab=0x411 status=0 aid=1)
[   32.514493] wlan0: associated

-> hier der Disconnect währed des Kopierens.

[  593.499310] wlan0: deauthenticated from 87:a8 (Reason: 7)
[  593.510400] cfg80211: Calling CRDA to update world regulatory domain
[  593.515180] cfg80211: World regulatory domain updated:
...
-> Reconect, bis zum nächste Abbruch

LessWire

Für dieses Verhalten im WLAN habe ich zwei Ursachen erfahren müssen:

- hardwaremässige Unverträglichkeit zwischen AP und Client (andere WLAN Hardware beim Client schaffte Abhilfe und war somit der Beweis)

- AP macht unerklärlicherweise immer wieder mal einen Reset (habe deshalb einen AP schon umgetauscht)

Habe aber auch schon erlebt, daß das Windows Notebook 🙁 von meinem Sohn gelegentlich mein Netzwerk wlan-seitig so ungünstig beeinflusst, daß zwei Rechner mit Atheros-Chip gar nicht mehr ansprechbar waren und nur ein reset geholfen hat. Er ist nur am Wochenende hier und hatte mit diesem Rechner auch immer Probleme sich ins Netzwerk einzuklinken - diese Probleme gab es aber nie mit seinem iphone (was ja eigentlich eher für meine Netzwerkhardware und deren Kompatibilität spricht, die sonst auch absolut zuverlässig dauerhaft läuft).

Wenn es bei Dir aber so ist, daß "netcfg" zuverlässig im Gegensatz zu NM arbeitet, liegt das Problem wohl eher beim NM. Für meine Belange reicht "netcfg" aus und wird schon immer verwendet.

skull-y

Die Probleme mit dem NM kann ich nachvollziehen, jedoch auf dem Netbook meiner Holden unter Xfce. Alle anderen Möglichkeiten wie eben netcfg, wpa_Duplikat und WICD haben keine Verbindungsabbrüche.

EDIT: Ich habe mal das nervig in netcfg gändert, da mein Handy aben ein nervig daraus gemacht hat. 🙂

GerBra

Ich konnte das beschriebene Verhalten gestern auch noch an einem anderen AP nachvollziehen.

Abschließend: Ich lasse dort NM erstmal drauf und weise auf die festgestellten Nachteile hin. Es tritt ja nur bei (hoher) "Dauerlast" auf, nicht beim eher normalen User/Surfverhalten (zumindest konnte ich das nicht einmal reproduzieren bei nur Surfen etc.). Wenn die Abbrüche mal zu einem Problem werden, dann kann man immer noch was ändern…

Reason 7 ist ja Client-Sache, d.h. es werden über die Verbindug noch versucht Daten zu transportieren obwohl der "Link"(Assoc) schon nicht mehr vorhanden ist. Meine Vermutung wäre dahingehend: Während des "Dauertransfers" (hier verringert sich ja auch meist die gemeldete Verbindungsrate, z.B. von guten 54MBit/s auf xx) erhält der NM Daten zum Zustand der Verbindung nicht mehr ausreichend schnell bzw. in einem Zeitfenster(Timeout). Dadurch wird - irrtümlicherweise - angenommen, daß der Link nicht mehr vorhanden ist und ein Dis-/Reconnect eingeleitet //Edit: *im NM*. Gleichzeitig findet aber immer noch der Datentransfer (hier rsync) statt, was das Kernelmodul dann zur Meldung/Zustand: "deauthenticated from xxx (Reason: 7)" bringt.
Hier ist wpa_supplicant wahrscheinlich "toleranter"/besser, da u.U. auch nicht soviele Statusdaten als zwingend verarbeitet/ausgewertet werden müssen.

Ich kenne nun leider keine Möglichkeiten, mit dem NM gerade bei solchen Werten zu spielen/verändern. Evtl. ändern ja auch Updates im Laufe der Zeit etwas daran. Wobei sich dieser Fall mit meinen eher schlechten Erfahrungen über die Jahre mit dem NM deckt - ich hatte mit unterschiedlicher Hardware/Umgebungen eigentlich nie Probleme eine Vebindung herzustellen (und das "Handling" war recht komfortabel und v.a. "schön bunt"!), aber in punkto Stabilität hatte ich regelmäßig solche negative Erfahrungen.

Wenn also noch jemand konkrete Vorschläge/Parameter/Configs etc. hat: her damit. Aber ansonsten denke ich hat es sich erledigt.