WLAN - nach ca. 24 Std. nicht mehr erreichbar.

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusammen,

    so ... jetzt ham wir den Salat ;) ...
    Ich teste gerade Pi No.2 im Dauerbetrieb allerdings zunächst ohne Last.

    Ich habe dieses Phänomen in der Vergangenheit schon auf dem ersten Pi beobachtet. Aber nachdem ich den derzeit mit anderen Dingen quäle, musste jetzt meine Neuerwerbung dran glauben.

    Der Pi hängt, gespeist von einem Hub mit ext. Stromversorgung ( 3A ), nur über WLAN im Netz. Keine Tastatur, keine Maus, kein gar nichts.
    Nach ca. einem Tag kommt bei einem Login-Versuch mit rlogin "No route to host" - und dann weiß ich mittlerweile schon, was los ist:


    Tja ... hat schon mal jemand was von dieser Erscheinung gehört?
    Hat einer von Euch vielleicht eine e-mail Adresse, wo man diesen Käfer hinschicken kann?

    Der komprimierte Syslog hat über 400 kb - die und ähnliche Meldungen stehen da zum Verfüttern drin.

    bye,
    -ds-

    Ach ja: das Teil läuft mit dem aktuellen wheezy und ist auch nicht getuned ;) ...

  • Ich betreibe nur einen meiner RPi's am LAN. alle anderen über WLAN. Was für eine Hardware ist auf dem WLAN-Stick verbaut - am verbreitetsten dürften die "rt8192cu" chips sein.
    Ich verwende die kleinen Edimax sticks und somit ausschließlich "8192cu" als Kernelmodul.

    Wichtig finde ich gerade auch bei WLAN, einen halbwegs aktuellen Kernel zu verwenden (3.6.x ist diesbezüglich schon angestaubt, >=3.8 wäre empfehlenswert, es sei denn, man hat aktuelle patches einfliessen lassen).

    Nun zur Zuverlässigkeit von WLAN bei mir mit diesem Chip, die Rt-Firmware dürfte soweit identisch sein, aber eben unter diesen Voraussetzungen (Kernelversion und wlan-chip):

    Ich habe den watchdog aktiviert, er ist so konfiguriert, daß jede Minute ein ping vom router bestätigt werden muß. Erfolgt nach spätestens 30 sec die Bestätigung nicht, wird der RPi neu gebootet (der watchdog macht nicht gleich einen hardreset, der RPi wird vorher sauber heruntergefahren wie es sich gehört).

    Diese WLAN bedingten resets passieren hier etwa 1-2 mal pro Tag (es gibt vereinzelt auch fehlerfreie Tage, aber - ebenso eher selten - Tage mit 5-6 resets). Dieses Verhalten ist bei allen meinen Wlan betriebenen RPi's identisch. Vom Router sind die RPi's dabei ca. 5m entfernt, allerdings auch eine Ziegelwand dazwischen.

    Was uns aber sehr wahrscheinlich distributionsspezifisch trennt: ich verwende "netctrl" für die Konfiguration und Steuerung des WPA2 Betriebs über wpasupplicant. Es gibt ja viele Feinheiten, Wlan ist ein komplexes Thema.

    Um es kurz zusammenzufassen:
    Die gleiche Hardware und Kernelversion vorausgesetzt, läuft Wlan recht zuverlässig und die Aussetzer sind dank des guten Watchdogs prima automatisch zu managen.

    Gruß, mmi

  • Moin mmi,

    hatte ich ganz vergessen aber bei den Kernel-Leuten eingekippt: das ist ein Logilink WL0084B mit einem RT5370 Chipsatz.
    Der wird, wenn ich mich recht erinnere, sogar auf der elinux-Seite empfohlen.

    Und seien wir mal ehrlich: mit einem watchdog per ping festzustellen, ob der Stick noch tut und evtl. den Pi zu rebooten kann's imho auch nicht sein ;) ...

    Hast Du mal im syslog nachgeschaut? Vielleicht ist das bei Dir ja genau das selbe Problem?

    Ich hab' mit meinen übrigen Teilen (Druckserver, Laptop) absolut kein Problem mit WLAN und hatte da in den letzten Jahren noch nie ein Problem, dass ich mal das eine oder andere rebooten musste.

    Wenn ich den Trace richtig interpretiere, dann besteht wohl ein Problem auf der Transportschicht. Möglicherweise ein Überschreiber oder so vielleicht in Zusammenhang mit DHCP. Das würde evtl. auch erklären warum viele hier kein Problem haben, da die meisten scheinbar fixe Adressen verwenden.

    Wird sich jedenfalls rausstellen, was dahinter steckt.

    Man sieht sich,
    -ds-

  • eine Lösung habe ich nicht.
    Mein Raspberry macht ähnliche Probleme. Habe ihn daher erst einmal zum Umtausch gegeben. Er lief 4 Wochen im Dauerbetrieb und endete dann auch so.
    In /var/log/messages standen Meldungen, die ich als Fehler im USB-Controller interpretiert habe.
    Es gab hintereinander Unmengen " new USB-Device detected "
    Bei jedem neuen Hänger habe ich auf das andere USB-Port umgesteckt und dann lief auch das Ethernet wieder (ohne RESET) .
    Datum und Uhrzeit wurden beim Hängenbleiben nicht weiter gezählt.
    Eine Stromüberlastung der USB-Schnittstelle scheidet auch aus, da außen nur ein HUB hängt, der am Paspberry vorbei versorgt wird (die 5V bekommt der HUB auch von außen, rote Leitung vom USB-Port zum HUB ist auch noch gekappt)

    4 Wochen Dauerbetrieb und dann jede 2... 3 Stunden, wie kann man das mit Software erklären ?


  • eine Lösung habe ich nicht.
    ...
    In /var/log/messages standen Meldungen, die ich als Fehler im USB-Controller interpretiert habe.
    Es gab hintereinander Unmengen " new USB-Device detected "

    ...

    Eine Stromüberlastung der USB-Schnittstelle scheidet auch aus, da außen nur ein HUB hängt, der am Paspberry vorbei versorgt wird (die 5V bekommt der HUB auch von außen, rote Leitung vom USB-Port zum HUB ist auch noch gekappt)

    4 Wochen Dauerbetrieb und dann jede 2... 3 Stunden, wie kann man das mit Software erklären ?

    Habe die Ehre, Dr. Günther ;) ...

    sorry, aber für mich klingt das dennoch nach einem Problem mit Deiner Stromversorgung.
    Ich war damals auch sicher, das ausschließen zu können (siehe hier), aber die Realität hat mich eines Besseren belehrt.
    Zudem geht es bei Ausfällen aufgrund der Stromversorgung nicht um eine "Stromüberlastung" sondern um eine Unterversorgung.

    Dass dieses Phänomen bei Dir erst nach 4 Wochen aufrat, kann verschiedene Ursachen haben. Aber da hab' ich den Arsch zu weit unten, wie man bei uns sagt.

    cu,
    -ds-


  • ... Logilink WL0084B mit einem RT5370 Chipsatz.
    ... mit einem watchdog per ping festzustellen, ob der Stick noch tut und evtl. den Pi zu rebooten kann's imho auch nicht sein ;) ...

    ... Hast Du mal im syslog nachgeschaut? Vielleicht ist das bei Dir ja genau das selbe Problem?

    ... Das würde evtl. auch erklären warum viele hier kein Problem haben, da die meisten scheinbar fixe Adressen verwenden.


    - im syslog keine Besonderheiten, bei Dir dann aber: anderer Chipsatz, andere Probleme ;)

    - watchdog: Natürlich ist es mit dem ping ein workaround, aber es wird andernorts schon lange kritisiert, daß bereits die proprietäre Firmware bugs hat, dann könnte nur Realtek selbst Abhilfe schaffen.

    - ja, ich verwende nur statische IPs

    vg, mmi


  • ...
    - ja, ich verwende nur statische IPs

    vg, mmi

    Hi,

    ok, also auch mit statischer IP tritt ein Problem auf ... interessant zu wissen.
    Da der trace was von _skb erzählte tippe ich nach wie vor auf die Transportschicht.
    Mir kam das irgendwie bekannt vor, weil ich bei Siemens mal eine Treiber-Zwischenschicht implementiert habe, um die Header zu manipulieren und die Pakete umzuleiten.

    cu,
    -ds-

  • Ich habe gerade einen Acer N53 dualband angeschlossen - Chipsatz rt3572 - Kernelmodul rt2800.
    Mal sehen, ob im Laufe des Abends noch was passiert ;)

    Edit (Test nach ca. 2 Std. beendet):
    Dieser Stick braucht nicht gerade wenig Saft, direkt angeschlossen gab es immer wieder mal Hänger. Ich weiss aber, daß er am aktiven Hub recht gut funktioniert hat.
    Sorry, dieser Beitrag ist deshalb erstmal für die Katz :(

  • Habe die Ehre, Dr. Günther ;) ...

    sorry, aber für mich klingt das dennoch nach einem Problem mit Deiner Stromversorgung.
    Ich war damals auch sicher, das ausschließen zu können (siehe hier), aber die Realität hat mich eines Besseren belehrt.
    Zudem geht es bei Ausfällen aufgrund der Stromversorgung nicht um eine "Stromüberlastung" sondern um eine Unterversorgung.

    Dass dieses Phänomen bei Dir erst nach 4 Wochen aufrat, kann verschiedene Ursachen haben. Aber da hab' ich den Arsch zu weit unten, wie man bei uns sagt.

    cu,
    -ds-

    jetzt mische ich mich schon wieder in eine (fast) andere Frage ein. Dein Hinweis ist schon ganz gut. Um Unterspannungen zu erkennen habe ich eigens einen ATMega zum Messen programmiert und im Abstand von 500ms gemessen und alles zum "Großen mit OpenSuSE" gesendet. Die Spannung am Mikro-USB-Stecker lag praktisch konstant zwischen 5,04 und 5,07 Volt.
    Wenn es Stromversorgung ist, dann kommt noch Störstrahlung des PT78HT205 in Betracht. Der ist direkt neben dem Raspberry platziert.

  • Hi,


    Zitat


    jetzt mische ich mich schon wieder in eine (fast) andere Frage ein. Dein Hinweis ist schon ganz gut. Um Unterspannungen zu erkennen habe ich eigens einen ATMega zum Messen programmiert und im Abstand von 500ms gemessen und alles zum "Großen mit OpenSuSE" gesendet. Die Spannung am Mikro-USB-Stecker lag praktisch konstant zwischen 5,04 und 5,07 Volt.
    Wenn es Stromversorgung ist, dann kommt noch Störstrahlung des PT78HT205 in Betracht. Der ist direkt neben dem Raspberry platziert.

    Zum Thema Störstrahlung kann ich leider nichts beitragen ... das übersteigt mein Knowhow bei Weitem.
    Zum Thema Messen würde ich vorschlagen, die Spannung nicht am Micro-USB sondern am GPIO oder dem + Messpunkt abzugreifen.
    Nach dem Micro-USB kommt noch die Polyfuse - vielleicht hat die nen Knacks ...

    cu,
    -ds-

  • Hallo ds,

    - hast Du es auch mal mit einer statischen IP probiert - die dann natürlich aus dem Vergabekontingent des DHCP Servers zu streichen wäre?
    - wie groß ist die leasetime des DHCP Servers je IP eingestellt ?
    - ca. 24 Std. zuverlässiger Betrieb ist schon ziemlich lang. Passiert es auch noch, wenn Du z.B. alle 20 Std. das WLAN Modul "restarten" lässt?
    - wie verhält sich der Stick am Linux-PC nach diesem Zeitraum (mit identischen Kernelversionen / identischer firmware)?

    Ich denke, so könnte man den Fehler noch besser eingrenzen und man wüsste, ob er sogar nur beim RPi auftritt. Die Portierung von x86 auf arm birgt ja durchaus gerade bei den Treibern "neues" Fehlerpotential.

    Gruß, mmi


  • http://raspberrypi.stackexchange.com/questions/1384…le-suspend-mode

    Der WLAN Adapter ist bzgl. Power Management richtig eingestellt?

    Hallo,

    danke für den Tipp ... leider ist das ein anderer Chipsatz als im Artikel beschrieben und ich finde auch keine Parameter im Modulverzeichnis.
    Ich glaube auch nicht, dass das ein Problem des Powermanagements ist. Der Adapter verabschiedet sich, wie ich mittlerweile herausgefunden habe (watchdog aktiviert und Router angepingt), mehrmals am Tag immer nach etlichen Stunden.

    cu,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!