Raspberry STRETCH wLan Adapter wlan0 reconnect funktioniert nicht

  • hier die Entropy:

    pi@raspberrypi:~ $ sudo sysctl -a | grep -i entropy

    kernel.random.entropy_avail = 837


    Wie wird der Software-Watchdog deinstalliert?

    Das ist wenig entropy. Versuch mal:

    Code
    1. sudo apt-get install haveged
    Code
    1. :~ $ cat /etc/default/haveged
    2. # Configuration file for haveged
    3. # Options to pass to haveged:
    4. # -w sets low entropy watermark (in bits)
    5. DAEMON_ARGS="-w 3072"

    nach den Änderungen in den Dateien (siehe oben):

    Code
    1. sudo systemctl daemon-reload
    2. sudo systemctl restart haveged
    3. sudo sysctl -a | grep -i entropy

    software-Watchdog deinstallieren:

    Code
    1. sudo apt-get remove --purge watchdog
    2. sudo dpkg --configure -a
    3. sudo apt-get clean

    Den hardware-Watchdog testen (wenn schon aktiv):

    Code
    1. ls -la /dev/watchdog*

    mit der forkbomb:

    Code
    1. :(){ :|:& };:
  • Ich fahre gleich mal zu einem KOLLEGEN. Mal sehen, ob der ein (wLan)Kabel hat. Sonst eben erst morgen. Ich hoffe, Du bist dann auch noch da. Jetzt erst ein mal vielen, vielen Dank für Deine Zeit, Hilfe und Geduld. Wenn alle Menschen so wären, dann wäre diese Welt besser. Nimm es als Kompliment - Carsten

  • Quote

    mit der forkbomb:

    Code

    :(){ :|:& };:

    1. das mit der Forkbomb kann ich nicht wechseln. Keine Ahnung was die Smiley-Atakke zu bedeuten hat


    2. mein Pi hat jetzt viel mehr zufällig Zufälligkeit (Entropie)

    pi@raspberrypi:/lib/systemd/system $ sudo sysctl -a | grep -i entropy

    kernel.random.entropy_avail = 3226

    sysctl: reading key "net.ipv6.conf.all.stable_secret"

    sysctl: reading key "net.ipv6.conf.default.stable_secret"

    sysctl: reading key "net.ipv6.conf.eth0.stable_secret"

    sysctl: reading key "net.ipv6.conf.lo.stable_secret"

    sysctl: reading key "net.ipv6.conf.wlan0.stable_secret"


    Watchdog:

    pi@raspberrypi:/lib/systemd/system $ ls -la /dev/watchdog*

    crw------- 1 root root 10, 130 Feb 10 15:17 /dev/watchdog

    crw------- 1 root root 252, 0 Feb 10 15:17 /dev/watchdog0

  • 1. das mit der Forkbomb kann ich nicht wechseln. Keine Ahnung was die Smiley-Atakke zu bedeuten hat


    2. mein Pi hat jetzt viel mehr zufällig Zufälligkeit (Entropie)

    pi@raspberrypi:/lib/systemd/system $ sudo sysctl -a | grep -i entropy

    kernel.random.entropy_avail = 3226

    Die entropy ist jetzt OK.



    Hast Du diese Zeichenfolge

    Code
    1. :(){ :|:& };:

    per copy&paste in die Kommandozeile eingegeben und danach die enter-Taste gedrückt? Wenn ja, dann musst Du warten, denn der PI sollte rebooten.

  • Sachen gibt es:

    Quote

    :(){ :|:& };:

    2. Das Python Skript gibt folgende Fehlermeldung (im anderen Terminalfenster)

    super(Connection, self).__init__(*args, **kwargs2)

    _mysql_exceptions.OperationalError: (2002, 'Can\'t connect to local MySQL server through socket \'/var/run/mysqld/mysqld.sock\' (111 "Connection refused")')

    Exception in thread Thread-1 (most likely raised during interpreter shutdown):


    2. die Terminalfenster reagieren nicht mehr


    3. neues Terminal-Fenster:

    ssh: connect to host 192.168.2.91 port 22: Host is down

  • Ja, diese Ausgaben sind ganz normal, denn so lange die forkbomb sämtliche ressourcen des Pi "auffrisst" reagiert dieser nicht mehr auf Verbindungsversuche und macht auch keine Ausgaben mehr. Die Frage ist die, ob der PI nach dem starten der forkbomb, durch den hardware-watchdog auch mal rebootet wird. Je nach dem wie "gehärtet" der PI ist, kann es aber dauern (... oder evtl. auch scheitern mit dem reboot?).

  • Oh je, mir schwant nix Gutes.

    Ich habe das Ethernetkabel besorgt.

    Ich habe die Ethernet-IP vergeben. Connectiert, funktioniert.

    Dann habe ich "meinen Test" gemacht:

    1. Ethernet und wLan aktiv -> der Fehler ist NICHT aufgetreten

    2. Ethernet getrennt und nur mit wLan, Fehler tritt auf.

    dann dachte ich, so jetzt gucke ich in Dich rein, jetzt gibst Du Dein Geheimnis preis.

    Aber NEIN, dem holden Ritter wurder der Eintritt verwehrt.

    Auch die Ethernetschnittstelle ist nicht erreichbar.

    Kein PING, kein SSH

    ich habe dann meinen Netzwerkscanner auf mein Netzwerk losgelassen,

    habe in der FBox nachgesehen, jein wLan und kein Lan-Kontakt.


    Und nach der Mistgabel-Attacke hatte sich gestern der Pi auch nicht zurückgemeldet.


    Ich bin deprimiert ?(

  • Dann habe ich "meinen Test" gemacht:

    1. Ethernet und wLan aktiv -> der Fehler ist NICHT aufgetreten

    2. Ethernet getrennt und nur mit wLan, Fehler tritt auf.

    Wird für "deinen Test" eine permanente/funktionierende Verbindung ins (W)LAN benötigt?

    Mach mal den Test nur mit Ethernet-Verbindung (d. h. ohne WLAN-Verbindung). Evtl. ist es so, dass der Test die WLAN-Infrastruktur des PI lahmlegt.

  • in meinem Python-Script werden auch andere Devices gePINGt. Wenn ich die Ethernetverbindung angesteckt habe, dann hat die Die IP90. IP90 bleibt in der Firewall stecken. Das macht dem Script nichts, es zeigt nur an, dass der Host XY nicht erreichbar ist.

    CPU-Auslastung:



    ganz links PI IDLE

    Spikes bei 1/4 Skript wird gestartet und läuft dann 4 mal durch

    Dann rechte der Spike, ich öffne über wLan oder über Ethernet (IP 91 0der 90) eins meiner LogFiles.


    Wenn kein Ethernet eingesteckt ist schmiert der Pi ja ab und ich sehe von dem TestSpike rechts nur die erste oder 2. Stufe (irgendetwas unter 25%) und dann kommt nichts mehr zum Pi durch, kein Ping, kein http, kein SSL.

  • Wenn kein Ethernet eingesteckt ist schmiert der Pi ja ab ...

    Evtl. liegt es daran, dass der PI in dieser Zeit eine Verbindung benötigt, die aber via WLAN nicht zur Verfügung gestellt werden kann, weil dem wpa_supplicant evtl. die erforderlichen Ressourcen "entzogen" werden. Mit der Ethernet-Verbindung kann das nicht passieren.


    Poste mal wenn der wpa_supplicant aktiv ist, die Ausgaben von:

    Code
    1. sudo prlimit --pid=$(pidof wpa_supplicant)
  • Aber wieso ist der Pi dann wenn Ethernet angesteckt wird nicht wieder über IP90 (Eth) erreichbar? Link LED leuchtet und Traffic LED flackert.

    Und am Pi sieht man ja auch noch den Heartbeat (Activity)?

  • Hier zum Vergleich der wpa_supplicant auf meinem PI:

    Ändere mal die niceness (NICE) und die real time priority (RTPRIO) für den wpa_supplicant auf deinem PI.


    EDIT:


    Code
    1. sudo prlimit --cpu=unlimited --pid=$(pidof wpa_supplicant) --core=65536: --nice=-17:-17 --rtprio=95:95
    2. sudo ethtool -K wlan0 gro off gso off


    Quote


    Aber wieso ist der Pi dann wenn Ethernet angesteckt wird nicht wieder über IP90 (Eth) erreichbar?

    Schau mal nach ob er mit der IP90 im arp-cache ist bzw. wie ist er nicht erreichbar? Auch mit arping nicht?

  • pi@raspberrypi:/ $ 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


    444, ich habe Angst, ich glaube an Dich, aber ich befürchte, wir haben uns verlaufen. Ich wollte doch nur einen funktionierenden wLan-Adapter mit RECONNECT, ist das so schwer? Ist der Weg wirklich so weit? Oder brauche ich DOCH ein neues STRETCH image?


    P.S.: habe noch nachinstalliert:

    sudo apt-get install ethtool net-tools

    Edited once, last by CaJo ().

  • Quote

    Schau mal nach ob er mit der IP90 im arp-cache ist bzw. wie ist er nicht erreichbar? Auch mit arping nicht?

    von einem andern Pi aus?

    nein, da bricht der PING dann ab bzw. 90 und 91 sind dann nicht mehr erreichbar


    pi@raspberrypi:~ $ sudo arping -I wlan0 -s 192.168.2.97 192.168.2.90

    ARPING 192.168.2.90 from 192-168.2.97 wlan0


  • was ist an einem cat - Befehl so rechenintensiv , dass alle Kerne in Aufregung versetzt werden? Lesen, versenden per ssh?

  • So, ich habe mir das RaspberryImage OHNE recommended Software heruntergeladen DIESES image auf eine neue SD-Karte installiert:

    Dann habe ich das System aktualisiert und konfiguriert. Vom Desktop aus habe ich mich an das wLan angemeldet. (dadurch wurde der wpa_supplicant Eintrag erstellt. Mit sudo nano /etc/dhcpcd.conf habe ich die statischen Adressen eingetragen:


    interface wlan0

    static ip_address=10.100.44.91/24

    static routers=10.100.44.60


    (nicht wundern, ich habe mich in mein Test-Netz 10.100.44.0/24 begeben.)

    ich habe jetzt auch eine Tastatur, eine Maus, und einen Monitor an 5 Meter HDMI-Kabel.

    Ethernet ist gerade nicht konfiguriert / verbunden.


    Und, der Fehler ist wieder da.


    Da das Python-Script alleine auch fehlerfrei läuft, habe ich gedacht, das ist ein Betriessystem(KONFIGURATIONS)fehler.

    Dann habe ich mir drei ssh-Terminal-Sitzungen aufgemacht und von allen das Logfile anzeighen lassen. Das dauert ca 25-31 Sekunden, wobei die Durchlaufzeiten der Terminals sehr unterschiedlich sind.


    Also cat funktioniert auch aus mehreren Terminalsitzungen.


    Nur wenn mein Script läuft, und in einer anderen Sitzung mit cat das log-File angezeigt wird, ist das Netzwerk weg.

    Dann dachte ich so bei mich :o) tadaa, kein Problem, jetzt kann ich ja den Pi mit dem Desktop mir ansehen. mit htop wird eine Auslastung von 3-4% angezeigt. Aber jetzs kommt es: lokale Webseiten über 10.100.44.91/.. können im internen Browser nicht mehr angezeigt werden.

    OK Neustart, damit der Pi nicht so hart auf trifft, heute mit HERUNTERFAHEN, oder NEUSTARTEN,

    das beginnt, wird aber nicht beendet schwarzer Bildschirm mit :plymouth-reboot-service, der nicht verschwindet.


    Ich bin ratlos wie es weiter gehen soll...

  • Aber jetzs kommt es: lokale Webseiten über 10.100.44.91/.. können im internen Browser nicht mehr angezeigt werden.

    OK Neustart, damit der Pi nicht so hart auf trifft, heute mit HERUNTERFAHEN, oder NEUSTARTEN,

    das beginnt, wird aber nicht beendet schwarzer Bildschirm mit :plymouth-reboot-service, der nicht verschwindet.

    Und das nur dann, wenn dein Python-Script aktiv ist?

    Kannst Du evtl. den Inhalt dieses Scriptes hier posten? Vielleicht erkennt ja jemand, was man anders machen könnte.