Raspberry STRETCH wLan Adapter wlan0 reconnect funktioniert nicht

  • nach dem nun eigentlich nur noch der Code übriggeblieben ist, bin ich nun auf der Suche. Ich reduziere jetzt mal den Code. Fastled habe ich schon probiert, da kann ich keinen Fehler nachvollziehen. Einer der nächsten Hauptverdächtigen ist mySQL, dieses ist mit STRETCH ja MariaDB geworden. Ich werde berichten, wie ,was weiter passiert.


    Edited 3 times, last by CaJo ().

  • Tja, alle Wege irrführend. Wenn mit mySQL ein Cursor aktiv ist, und auf diesen zugegriffen wird, dann kommt es zu dem wLan-Lan-Absturz. Komisch dabei ist, dass die try - except - Blöcke keinen Fehler (aus)werfen.


    Ich wähnte mich schon auf dem richtigen Weg, dann habe ich noch einmal ein FASTled Beispiel durchorgeln lassen. (Brightness=25 also Netzteil ausgeschlossen). Ich war heute Nachmittag anderweitig beschäftigt. Dann nach ca. 4 Stunden habe ich bemerkt, dass der Pi (wLan , Lan) wieder geschreddert war.


    ??? Ich weiß nicht weiter ??? bin auch analytisch am Ende ???

  • strandtest.py ist aus Neopixel - python - examples.

    und der cat-Befehl wird in einer anderen Terminalsitzung ausgeführt.

    oder keine andere Sitzung, dann nach irgendeiner Zeit -steigt der Pi aus.

    Files

    • strandtest.py

      (4.42 kB, downloaded 14 times, last: )
  • ja, keine Fehler mit cat, aber ich habe nur 10 mal probiert. Gerade vor 2 Minuten ist der pi ohne laufendes script abgeschmiert. (ich habe in der ssh Sitzung Quelltext editiert) ...

  • Hofei

    das sind alles Ideen, den Fehler zu isolieren, zu reduzieren, die aber ALLE ins LEERE gelaufen sind.


    Ich fasse mal zusammen: irgendwann ist auf einmal das wLan und der Ethernetanschluss weg, wenn da noch ein Monitor dran hängt, kann der Pi nicht mehr neugestartet / heruntergefahren werden.


    Je mehr die wLan-Schnittstelle genutzt wird, umso schneller tritt das Problem auf. Nur mit der Ethernetschnittstelle tritt der Fehler nicht auf.

  • Ich fasse mal zusammen: irgendwann ist auf einmal das wLan und der Ethernetanschluss weg, wenn da noch ein Monitor dran hängt, kann der Pi nicht mehr neugestartet / heruntergefahren werden.

    Ja, aber dein PI stürzt "nicht richtig ab", denn wenn das der Fall wäre, dann würde der hardware-Watchdog deinen PI rebooten, was er aber nicht macht.


    Jetzt solltest Du mit einem cronjob testen, ob dieser cronjob noch ausreichend Ressourcen hat, deinen PI zu rebooten wenn die WLAN-Verbindung bzw. die Ethernet-Verbindung weg ist.

  • das haben wir ja schon ausprobiert. Selbst, wenn ein Monitor am Pi ist, dann kann der Pi nicht HERUNTERGEFAHREN werden, der bleibt dann stecken.

  • Selbst, wenn ein Monitor am Pi ist, dann kann der Pi nicht HERUNTERGEFAHREN werden, der bleibt dann stecken.

    Ja, aber das ist nicht maßgebend, denn wenn Tastatur/Monitor nicht mehr erreicht werden können, heißt das nicht, dass ein cronjob da nicht erfolgreich sein könnte. Aber OK, dann lassen wir das.


    Eine andere Ursache bzw. Vorgehensweise fällt mir da ein. Ich denke es wird so sein, dass beim Traffic über das wlan-Interface deines PI, der Treiber/Firmware des wlan-Interface die "segmantation/fragmentation" macht und nicht der Kernel deines PI. Der Treiber bzw. die Firmware wird da evtl. überfordert sein (bei der Menge an Daten) und hängen bleiben.

    Konfiguriere deinen PI mal so, dass der Kernel diese "segmantation/fragmentation" für den Traffic über das wlan-Interface macht.


    EDIT:


    Vergleiche mal die Ausgabe auf deinem PI mit dieser Ausgabe:

  • Konfiguriere deinen PI mal so, dass der Kernel diese "segmantation/fragmentation" für den Traffic über das wlan-Interface macht.

    Kannst Du mich mals aufs Pferd setzten -> keine Ahnung wie das geht.

  • Wie stellt man fest, welcher wLan-Chip wirklich onBoard verbaut ist, und dass dafür auch der richtige Treiber im System verankert ist. Nicht, dass der Adapter im "Kompatibilitätsmodus" läuft?


    Angaben folgen ...


  • sudo ethtool -k wlan0

  • modinfo brcmfmac




    uname -a

    Code
    1. Linux Raspberry2019 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux


    cat /boot/config.txt






  • sudo ethtool -k wlan0

    Auf meinem PI3 habe ich gro und gso auf off:

    Code
    1. 18,19c18,19
    2. < generic-segmentation-offload: off
    3. < generic-receive-offload: off
    4. ---
    5. > generic-segmentation-offload: off [requested on]
    6. > generic-receive-offload: on

    Mach mal auf deinem PI:

    Code
    1. sudo ethtool -K wlan0 gro off gso off

    und teste. Hast Du die Ausgabe von "sudo sysctl -p" schon gepostet?

  • sudo ethtool -K wlan0 gro off gso off

    Cannot get device udp-fragmentation-offload settings: Operation not supported

    Cannot get device udp-fragmentation-offload settings: Operation not supported

  • sudo ethtool -K wlan0 gro off gso off

    Cannot get device udp-fragmentation-offload settings: Operation not supported

    Cannot get device udp-fragmentation-offload settings: Operation not supported

    Das ist normal, wichtig ist jetzt die Ausgabe von:

    Code
    1. generic-segmentation-offload: off
    2. generic-receive-offload: off

    statt

    Code
    1. generic-segmentation-offload: off [requested on]
    2. generic-receive-offload: on