staging.inyokaproject.org

Wenn wir noch einen zuverlässigen Hinweis hätten, wie Störungen seitens anderer Netze und Abbrüche der WLAN-Verbindung korrelieren, wären wohl für's erste genügend Unterlagen beisammen. Doch im Moment steht meine Verbindung recht stabil, und ich kann nicht zu den Nachbarn gehen und sie bitten, ihr WLAN allesamt gleichzeitig einzuschalten und zu benützen, wie es am Sonntag war. Deshalb warte ich weiter auf zufällige Beobachtungen.

So, ich habe den "Bug" als "question/694566" https://answers.launchpad.net/ubuntu/+question/694566 bei launchpad.net geposted. Mal sehen, wer (und ob) sich darauf meldet. Wenn man sich bei launchpad.net angemeldet hat, kann man zu diesem Post auch im Textfeld "Message" etwas eintragen und mit "Just add a comment" oder "I'm providing more information" abschließen.

Ich habe mich bei der question mit eingeklinkt und meine Hardware-Informationen angegeben.

Doch seltsam: Zur Zeit habe ich keine Abbrüche mehr (Kernel 5.4.0-58-generic). Kann aber ein Zufall sein. Die Angaben von shiro beweisen ja, dass das Problem auch bei diesem Kernel noch besteht.

Ich muss mich an einer Stelle korrigieren. Bisher hatte ich Verbindungsabbrüche nur im 2,4GHz Band und keine im 5GHz Band. Heute hatte ich allerdings auch Abbrüche im 5GHz Band.

Grund: Normalerweise sind ca 20 SSIDs im 2,4GHz Band aktiv, im 5GHz Band war nur ich allein. Das hat sich seit heute geändert, da einer der Nachbarn das 5GHz Band auch aktiviert hat und mein Router von Kanal 36 auf 52 wechselte. Die Einträge im syslog sind bis auf die MACs identisch.

Zunächst:

@shiro: Ich hatte mich bei Deiner Anfrage bei Launchpad wie von Dir vorgeschlagen mit eingeklinkt, habe das aber wohl etwas ungeschickt gemacht. Es ist der Eindruck entstanden, dass ich Deine Anfrage entführen wollte. Das war keineswegs der Fall, ich wollte nur behilflich sein.

Eine Anfrage ist kein Bug-Report, und ich verstehe es, dass es für den Antwortenden schwierig wird, wenn da von Anderen noch ergänzende Fragen mit eingebracht werden. Bei einem Bug-Report ist das anders: Da möchte man ja, dass möglichst viele ihre Beobachtungen und Feststellungen, auch ergänzende Fragen, mit einbringen. Ich war etwas unachtsam und habe nicht aufmerksam genug zwischen Question und Bug Report unterschieden. shiro, bitte entschuldige!

Nun zur Sache:

Deine neuerlichen Beobachtungen im 5-GHz-Band bestätigen meine Beobachtung, dass die Abbrüche bevorzugt (bei mir sogar ausschließlich) dann stattfinden, wenn noch fremde SSIDs im gleichen Band vorhanden sind. Ich wohne da etwas günstiger, wochentags bin ich oftmals allein im Band, und da passiert dann auch nichts.

Diese Beobachtung passt gut zu der Interpretation, die kB weiter oben (12. Dezember 2020 17:45 (zuletzt bearbeitet: 12. Dezember 2020 17:47) abgegeben hat.

Es war auch kB, der zuerst die Frage, ob nur Intel-Hardware betroffen ist, aufgeworfen hat. Diese Frage ist meines Erachtens auch wichtig.

Meines Erachtens handelt es sich recht eindeutig um einen Bug (erneute Abfrage des Schlüssels bei Änderungen der Verbindung, obwohl dieser hinterlegt ist und automatisch übernommen werden sollte). kB hat für den Report oben schon ein paar Hinweise gegeben (17. Dezember 2020 15:16). Doch bitte, shiro, schreibe Du den Bug-Report. Sonst sieht es wirklich so aus, wie wenn ich die Angelegenheit "hijacken" wollte. Mit Deinem Einverständnis werde ich mich dann gleich als "ebenfalls Betroffen" eintragen.

Noch eine Frage: Kannst Du die Häufigkeit der Abbrüche verringern, indem Du am Router (nicht nur am Laptop) für Dein WLAN einen festen Kanal einstellst? Denn wenn der Router automatisch jeweils den günstigsten Kanal aussucht, können ja Kanalsprünge erfolgen, wenn die Belastung durch fremde SSIDs sich ändert. Und möglicherweise sind es solche Kanalsprünge, die eine erneute Abfrage des Schlüssels auslösen (??). Doch auch wenn dieses Workaround helfen sollte, ist damit das eigentliche Problem (der Bug) natürlich noch nicht gelöst.

Gruß – Max-Ulrich

Zum Lauchpad Eintrag: Ich wollte ja einen Bug Eintrag machen. Beim Durchlesen der Prozesse zur Meldung eines solchen stellte ich allerdings fest, dass die Abläufe eher für Crash-Analysen entworfen sind. Der hier vorliegende Fall eines intermittierenden Problems war für mich nicht erkennbar aufgezeigt. Aus diesem Grund hatte ich die Form der "Question" gewählt, in der Hoffnung dort Unterstützung bei der Formulierung und Einhalten der Formalien des Bug-Reports zu bekommen. Ich habe vor, ca 1 Woche das Thema bei den Questions zu lassen. Sollte es dort nicht vernünftig aufgegriffen werden, versuche ich das Thema als "Bug" nach Weihnachten einzutragen, in der Hoffnung, das es formal als solcher akzeptiert wird.

Zum 5GHz Problem: Die Einträge im syslog, die dem Verbindungsabbruch vorausgehen sehen bei 2,4GHz und 5GHz gleich aus. Ich denke, dass man die Häufigkeit der Fehler vermindern kann, wenn man die Wechsel (Kanalwechsel im Router oder Wechsel des Verbindungsweges zum Router (Repeater)) im Netz reduziert. Daher denke ich, dass ein fest eingestellter Kanal im Router weniger Verbindungsabbrüche zur Folge haben wird, die durch Kanalwechsel im Router bewirkt werden. Man drängelt dann die anderen Router zum Kanalwechsel. Ausprobiert habe ich das allerdings noch nicht. Die durch Betrieb mit Repeatern(Mesh) verursachten Verbindungsabbrüche werden hierdurch aber nicht beeinflusst.

Oops... Ich habe es hinbekommen und das Problem als Bug #1908823 gemeldet (https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1908823)

Das ganze war nicht so einfach, da zum Melden eines Bugs das Internet laufen muss und gleichzeitig zum Erfassen des Problems mit der vorgeschriebenen Software (ubuntu-bug) das WLAN aber abgebrochen ist. Na ja, nun ist es jedenfalls auch als Bug gemeldet. Mal sehen, was nun an weiteren Aktionen erforderlich ist.

Bandbreite im Router ist auf 20MHz anstatt 20/40? Kanal fest eingestellt? Nutze auch LinSSID um freie Kanäle zu finden

@praseodym: Bei der Fritzbox 7590 habe ich sowohl im 2,4GHz als auch im 5GHz Frequenzband die automatische Einstellung gewählt (default). Man kann aber die Frequenzen auch individuell fix einstellen. Eine Übersicht wie in LinSSID bekommt man bei der Fritzbox aber auch. Dazu hat man auch die aktuelle zeitliche Auslastung des aktuellen Kanals. Im 2,4GHz Band arbeiten alle über 20MHz.

Normalerweise ist diese automatische Zuordnung auch ideal, da man stets den am wenigsten belasteten Kanal erhält. Zur Lösung des aktuellen Problems möchte ich allerdings die Konfiguration nicht ändern, um eventuelle Nachfragen seitens Ubuntu in gleichem Environment beantworten zu können.

shiro schrieb:

[…] Problem als Bug #1908823 gemeldet (https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1908823)

Danke.

Ich habe dort das Problem bestätigt (confirmed), was bei Bugs auf Lauchpad.net wichtig ist, damit diese ernst genommen werden.

Außerdem habe ich von Launchpad.net zurück auf diese Diskussion bei UbuntuUsers.de verknüpft.

Alle vom BUG betroffenen sollten sich auf Launchpad.net als ebenfalls Betroffene unter „This bug affects 2 people“ (wird nach Anmeldung bedienbar) melden. Dies steigert die Wichtigkeit ("heat") dieses BUG.

Ich habe dort das Problem ebenfalls bestätigt.

Allerdings habe ich so gut wie keine Abbrüche mehr, seitdem ich die automatische Kanal-Zuordnung abgeschaltet und von Hand einen wenig belasteten Kanal ausgewählt habe. Ich habe dann sowohl den Router als auch das Laptop auf diesen Kanal fixiert. Seither ist Ruhe.

Das heißt aber nicht, dass das Problem gelöst ist: Auch mit "automatischer Kanal-Zuordnung" müsste es funktionieren!

Für eine brauchbare Statistik sind die Zahlen zu gering. Trotzdem habe ich den Eindruck, dass mit dem Kernel 5.4.0-58 die Abbrüche weniger geworden waren. Einen Repeater habe ich nicht in Betrieb.

Offenbar spielen da zwei Dinge zusammen:

1. Es muss erst 'mal zu "Abbrüchen" kommen.

2. nach einem "Abbruch" (besser: Veränderung bei laufender Verbindung) wird für die Wiederherstellung (besser: Aktualisierung) der Verbindung der voreingestellte Schlüssel nicht ordnungsgemäß übernommen.

Möglicherweise hat sich Punkt 1. beim Kernel-Update verbessert, sodass der nach wie vor nicht gelöste Punkt 2. eben weniger häufig beobachtet wird (??). Punkt 1. kann shiro mit seinem Repeater provozieren, ich nicht. Wenn ich hingegen das Netzwerk aus- und wieder einschalte, gilt dies als Neuverbindung, und da funktioniert die Übernahme des voreingestellten Schlüssels.

Wirklich eine vertrackte Situation!

Also ich habe als Router eine FritzBox 7490. Dort habe ich jetzt die automatische Kanalsuche abgestellt und einen festen Kanal gesucht (13). Den 5 GB Kanal deaktiviert und das WLAN umbenannt. Verschlüsselung WPA2. Seit dem (vor vier Tagen) hatte ich bislang keine Abbrüche und Neu- Abfragen des Schlüssels mehr .... Werde es weiter beobachten.

Max-Ulrich_Farber schrieb:

[…] Offenbar spielen da zwei Dinge zusammen:

1. Es muss erst 'mal zu "Abbrüchen" kommen.

Meine Hypothese: Die Abbrüche entstehen, wenn es zur Kollision verschiedener WLAN-Netze in demselben Funkkanal kommt. Dann müssen sich die Teilnehmer jedes Netzes wieder gegenseitig identifizieren und authentifizieren. Das ist in WLAN-Netzen nicht ungewöhnlich und geschieht sogar auch im ungestörten Betrieb regelmäßig. Wenn jedoch die Schlacht um die Funk-Hoheit zu heftig tobt, wird dieser Vorgang so oft ausgeführt, dass eine Ressource in der Treiber-Software erschöpft wird (Die Fehlermeldung spricht ja von einen nicht verfügbaren Puffer.) und es wird in einer höheren Eskalationsstufe nach dem Schlüssel gefragt.

2. nach einem "Abbruch" (besser: Veränderung bei laufender Verbindung) wird für die Wiederherstellung (besser: Aktualisierung) der Verbindung der voreingestellte Schlüssel nicht ordnungsgemäß übernommen.

Der Schlüssel ist ja noch vorhanden und soll nur bestätigt werden. Die Software ist nur nach mehreren automatischen Fehlversuchen bei der Authentifizierung in einer höheren Eskalationsstufe und verunsichert und fragt nun nach: „Ist dieser Schlüssel wirklich richtig?“. Leider kommt das über das Bedieninterface beim Benutzer irritierend und missverständlich darüber. Nervig ist das natürlich auch.

Möglicherweise hat sich Punkt 1. beim Kernel-Update verbessert

Vielleicht hat man einfach die Anzahl der benötigten Fehlversuche bis zum Eintritt in die erhöhte Eskalationsstufe hoch gesetzt. Vielrecht hat man den Speicherplatz für den Puffer vergrößert. Vielleicht gibt es sogar für wpa_supplicant oder iwlwifi oder im NetworkManager dafür einen Konfigurationsparameter. Das sind leider alles nur plausible Spekulationen, welche auf meiner Hypothese (also auch bereits nur Spekulation) beruhen.

sodass der nach wie vor nicht gelöste Punkt 2. eben weniger häufig beobachtet wird (??).

Oder es kommt jetzt einfach zu weniger Kollisionen im Funkkanal.

Punkt 1. kann shiro mit seinem Repeater provozieren

Was meine Hypothese stützt und mir als vernünftiger Ansatz erscheint: Man kann parallel zu seinem WLAN-Netz in demselben Funkkanal mit anderen Geräten ein weiteres unabhängiges WLAN-Netz betreiben und durch heftigen Verkehr die Anzahl der Kollisionen erhöhen und damit Abbrüche provozieren (sofern meine Hypothese zutrifft).

kB schrieb:

Max-Ulrich_Farber schrieb:

[…] Offenbar spielen da zwei Dinge zusammen:

1. Es muss erst 'mal zu "Abbrüchen" kommen.

Meine Hypothese: Die Abbrüche entstehen, wenn es zur Kollision verschiedener WLAN-Netze in demselben Funkkanal kommt.

Ich hatte auch die ständigen Schlüsselabfragen nach Installation des aktuellen Kernels. Mit einem TP-Link WN821N Stick(Atheros). Dann habe ich einen anderen Stick mit Realtek Chip eingesteckt(TP-LINK WN725N) und die Abfragen treten nicht mehr auf. Ich glaube aber nicht, dass es mit den verschiedenen Chipsätzen zu tun hat, sondern der Atheros Stick hat normale Größe mit entsprechender Antenne. Der Realtek Stick hat Mikroformat mit entsprechend winziger Antenne. Er empfängt auch deutlich weniger fremde SSIDs und vermutlich kommt es daher zu keinen Kollisionen mit anderen Netzen.

@Celeron:

Er empfängt auch deutlich weniger fremde SSIDs und vermutlich kommt es daher zu keinen Kollisionen mit anderen Netzen.

Also: Je besser die Netzwerk-Schnittstelle, desto mehr Abbrüche? – Mein altes ASUS-Netbook hatte nie Abbrüche, meine beiden Lenovo Thinkpads schon. Mit gleicher Xubuntu-Version und gleichem Kernel, alle AMD-64.

Doch ich bezweifle, dass alles so einfach ist.