Raspberry Pi3 - WLAN Totalausfall

Begonnen von Felix_86, 26 Juli 2018, 13:15:11

Vorheriges Thema - Nächstes Thema

Felix_86

Hallo zusammen,

mir ist klar, dass es sich hier nicht um ein Raspberry Forum handelt, da diese Plattform hier aber durchaus verwendet wird, hat evtl. der eine oder andere Erfahrungen gemacht und kann Tipps geben.

Zum Hintergrund:
Ich habe ein Firmware / Kernel Upgrade des Raspberry durchgeführt. Anleitung und Software siehe https://github.com/Hexxeh/rpi-update
Firmware / Kernel Originalzustand: 4.9.35-v7+
Firmware / Kernel nach Update: 4.14.17-v7+

Die WLAN Verbindung funktioniert nach einem Start des Pi immer problemlos, stabil und schnell. Die Antwortzeiten eines Pings sind im grünen Bereich, der Pi ist per HTTP und SSH erreichbar.

Geht die WLAN Verbindung allerdings mal verloren, kommt in der Nacht häufiger vor oder starte ich den Router neu, dann war es das mit WLAN am Pi.
- ein "sudo iwlist wlan0 scan" liefert gar keine WLAN Netze mehr und läuft in einen Timeout
- "ifconfig -a" zeigt kein wlan0 Interface mehr an
- das WLAN Symbol im Systemtray ist mit 2 roten X gekennzeichnet

Folgende Maßnahmen habe ich nun versucht:
- Restart diverser Dienste und Prozesse in verschiedenen Abhängigkeiten und Reihenfolgen -> erfolglos
- "set power_save off" in /etc/network/interfaces -> erfolglos
- Versuche der Früherkennung eines WLAN Verlusts -> erfolglos
- Reboot des kompletten Pi -> erfolgreich*

* Allerdings ist hierbei zu beachten, dass der Shutdown-Vorgang 5 Minuten bei "plymouth-reboot.service" hängt. Danach findet der Reboot schnell und ordentlich statt und der Pi kommt wieder mit dem wlan0 Interface hoch.

Als Workaround habe ich mir nun ein FHEM AT erstellt, dass jeden morgen einen Reboot des kompletten Pi durchführt. Das funktioniert zwar, kann aber keine Lösung sein.

Hat jemand gleiche Erfahrungen gemacht?

Besten Dank.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

Otto123

Hi,

was hast Du für einen Router? Fritzbox und Wlan Chip/Treiber des Raspberry sind kein gutes Paar ...

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: Otto123 am 26 Juli 2018, 13:19:07
was hast Du für einen Router? Fritzbox und Wlan Chip/Treiber des Raspberry sind kein gutes Paar ...
@Otto:
Das schreit eigentlich nach dem hier: https://wiki.fhem.de/wiki/Raspberry_Pi#Bekannte_Probleme

Abhilfemaßnahme(n): Kabel verwenden... (oder irgendwas an den Powereinstellungen rumnudeln oder einen besseren WLAN-Chip@USB nehmen oder gleich was anderes als einen Pi als Server verwenden; zwischenzeitlich kann ich krikan in seiner Pi-Skepsis echt gut verstehen 8) )
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

@Beta-User Du meinst ich soll da was eintragen?  ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: Otto123 am 26 Juli 2018, 13:31:40
@Beta-User Du meinst ich soll da was eintragen?  ;)
Es sollte jemand sein, der weiß, was er tut ;D . Daher hatte ich schon an dich gedacht ;) .

Bekennendermaßen war mein letzter Pi ein PI2 - ohne WLAN, BT und anderen Schnickschnack, über den Erstanwender in zunehmenden Maß fallen >:( .
Keine Ahnung, warum Leute auf solchen "eierlegenden Wollmilchsäuen" stehen und die bekannten Probleme der schlecht aufeinander abgestimmten Komponenten erst mal ignorieren ::) .

@Felix_K: Nur für den Fall, dass du das Ding auch wegen der GPIO's haben wolltest: Finger davon weglassen, das steht sonst ggf. nur später mal einen Umzug auf andere Hardware im Weg ;) . Ausnahmen: Fertige Hardware-Module, z.B. für HM oder eine RTC. Die Module für die serielle Schnittstelle kann man ggf. auch an anderen Plattformen mit einem USB-Seriell-Wandler betreiben.

Just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

@Otto:Wenn du schon dabei sein solltest:
- Wie wäre es mit einem Hinweis, dass Steckerziehen zu korrupten SD-Karten führen kann?
- und überhaupt wegen der SD-Karten: Umstieg auf USB-Stick sinnlos, dafür erforderlich aber eine Strategie, wie man im Falle des Ausfalls der SD-Karte schnell wieder einen funktionfähigen Server aufzieht... (ich gebe zu, das ist kein reines Pi-Thema, bei dem aber besonders wichtig!)

Bestimmt fällt dir auch noch was ein, das war jetzt nur "aus der Hüfte..."

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Felix_86

#6
Zitat von: Otto123 am 26 Juli 2018, 13:19:07
was hast Du für einen Router? Fritzbox und Wlan Chip/Treiber des Raspberry sind kein gutes Paar ...
In der Tat "hängt" der Pi per WLAN an einer Fritzbox. Aber warum fliegt dann am Pi das ganze wlan0 Interface weg, nur weil ich z.B. die FritzBox neustarte? Gibt die Fritzbox heimliche Kommandos an den Pi zur Selbstverstörung? :o
Ich habe noch einen Telekom Hybrid hier stehen. Bedarf zwar etwas an Umbau am Pi / FHEM, aber für einen Test durchaus sinnvoll.

Zitat von: Beta-User am 26 Juli 2018, 13:23:58
@Otto:
Das schreit eigentlich nach dem hier: https://wiki.fhem.de/wiki/Raspberry_Pi#Bekannte_Probleme
In meinem Fall kommt ein 3A Netzteil zum Einsatz. Die zahlreichen USB Geräte können so auch dauerhaft versorgt werden.
Ein kompletter Absturz des Pi bei zu geringer Spannungsversorgung wäre nachvollziehbar. In meinem Fall läuft der Pi weiter (KVM ist angeschlossen).

Zitat von: Beta-User am 26 Juli 2018, 13:23:58
Abhilfemaßnahme(n): Kabel verwenden... (oder irgendwas an den Powereinstellungen rumnudeln oder einen besseren WLAN-Chip@USB nehmen oder gleich was anderes als einen Pi als Server verwenden; zwischenzeitlich kann ich krikan in seiner Pi-Skepsis echt gut verstehen 8) )
Kabel nicht möglich, Powereinstellungen an welchem Gerät rumnudeln?, die 4 USB Ports sind belegt

Zitat von: Beta-User am 26 Juli 2018, 13:39:44
@Felix_K: Nur für den Fall, dass du das Ding auch wegen der GPIO's haben wolltest: Finger davon weglassen, das steht sonst ggf. nur später mal einen Umzug auf andere Hardware im Weg ;) . Ausnahmen: Fertige Hardware-Module, z.B. für HM oder eine RTC. Die Module für die serielle Schnittstelle kann man ggf. auch an anderen Plattformen mit einem USB-Seriell-Wandler betreiben.
Komisch, dass ich den Pi zu Beginn meiner Smart Home Erfahrungen als so gutes und vielseitiges System empfohlen bekommen habe und mir nun an vielen Stellen davon abgeraten wird.
Meine Erfahrungen mit anderer Hardware habe ich bereits gemacht ;) https://forum.fhem.de/index.php/topic,77215.msg821490.html#msg821490



Zitat von: Beta-User am 26 Juli 2018, 13:45:07
@Otto:Wenn du schon dabei sein solltest:
- Wie wäre es mit einem Hinweis, dass Steckerziehen zu korrupten SD-Karten führen kann?
- und überhaupt wegen der SD-Karten: Umstieg auf USB-Stick sinnlos, dafür erforderlich aber eine Strategie, wie man im Falle des Ausfalls der SD-Karte schnell wieder einen funktionfähigen Server aufzieht... (ich gebe zu, das ist kein reines Pi-Thema, bei dem aber besonders wichtig!)

Bestimmt fällt dir auch noch was ein, das war jetzt nur "aus der Hüfte..."
Das ist hier in diesem Thread alles kein Thema. Ich frage gezielt zum Thema WLAN und möchte nicht über SD-Karten und Systemwiederherstellung informiert werden. Wenn ich dazu eine Frage habe, starte ich einen entsprechenden Thread.
Zwar habe ich erst eine Handvoll Beiträge verfasst, ich beschäftige mich aber schon einige Zeit mit dem Thema, recherchiere und probiere vorher ausführlich, bevor ich mich an euch wende. Ich bin auch im Unix/Linux Umfeld nicht fremd und weiß mir zu helfen.


Generell fällt mir in diesem Forum auf, dass Threads sehr schnell totgeschrieben werden und völlig vom eigentlichen Thema abweichen. Das ist sehr schade, denn es steckt viel Wissen und Potenzial in den Benutzern und es wäre für alle einfacher, wenn man konkreter und beim Thema bleiben würde.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

Beta-User

Zitat von: Felix_K am 26 Juli 2018, 14:42:35
Powereinstellungen an welchem Gerät rumnudeln?,
Ok, dann mal nur on topic:

startpage.com liefert mit "Raspberry wlan power" ziemlich vorne folgendes: https://www.kuerbis.org/2016/03/raspberry-pi-3-kurztipps-wlan-sleep-mode-verhindern/

Ob das weiterhilft, kann ich aber nicht sagen, da ich - wie ausgeführt - den Pi aus besagten Gründen ausgemustert habe und nur das Stichwort noch im Hinterkopf war.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Hallo Felix_K,

ich habe mir das vor geraumer Zeit mal angesehen. Die FB und deren Wlan setzt die Linux Treiber arg unter Stress, das kann man irgendwo im log sehen. Das Problem hatte ich in jedem Linux (mit Wlan) gesehen, nach außen aufgetreten ist es nur bei den Pi onBoard Chips - ich vermute dort einen Bug und unter Stress tritt der nach kurzer Zeit zu Tage, ohne Stress wahrscheinlich erst nach einem Jahr. Aber das ist die pure Vermutung.
Ich hatte aber auch vergleichbare Probleme mit ESP8266!

Ich hatte zwei Abhilfen:
- anderen Accesspoint, OpenWrt und der Pi war still und stieg nicht aus. Die ESP8266 arbeiten sauber.
- anderen WlanUSB Stick, der pi stieg nicht mehr aus.

Ich hatte noch damit experimentiert alle Optimierungen und Automatismen in der FB zu deaktivieren - das hat es etwas besser gemacht. Beseitigt wurde das Problem mit neuem Wlan / OpenWrt (ich hatte Anfangs ne alte Easybox umgeflashed)

Gruß Otto

P.S. die oft beschriebenen Power Einstellungen haben bei mir nie geholfen. Ich betreibe die Pi's (3 und 3+ und ZeroW) mit Standardkonfig -> läuft.  :D
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Felix_86

#9
Zitat von: Beta-User am 26 Juli 2018, 14:49:28
Ok, dann mal nur on topic:

startpage.com liefert mit "Raspberry wlan power" ziemlich vorne folgendes: https://www.kuerbis.org/2016/03/raspberry-pi-3-kurztipps-wlan-sleep-mode-verhindern/

Ob das weiterhilft, kann ich aber nicht sagen, da ich - wie ausgeführt - den Pi aus besagten Gründen ausgemustert habe und nur das Stichwort noch im Hinterkopf war.
Kenne ich, habe ich natürlich auch schon gesehen und umgesetzt, wie bei der Threaderstellung zu sehen (""set power_save off" in /etc/network/interfaces -> erfolglos"), funktioniert aber nicht.

Zitat von: Otto123 am 26 Juli 2018, 14:56:32
Hallo Felix_K,

ich habe mir das vor geraumer Zeit mal angesehen. Die FB und deren Wlan setzt die Linux Treiber arg unter Stress, das kann man irgendwo im log sehen. Das Problem hatte ich in jedem Linux (mit Wlan) gesehen, nach außen aufgetreten ist es nur bei den Pi onBoard Chips - ich vermute dort einen Bug und unter Stress tritt der nach kurzer Zeit zu Tage, ohne Stress wahrscheinlich erst nach einem Jahr. Aber das ist die pure Vermutung.
Danke für die ausführliche Schilderung.
Aber wie kann die FB den Treiber so streßen, wenn ich die FB neustarte oder gar ausschalte und danach der Pi kein wlan0 Interface mehr hat?
Wird da nochmal ein "Broadcast" über den Äther geschickt, der dann den Fehler auslöst und das WLAN am Pi abschießt?
Und wenn es sich um einen Softwarefehler handelt, warum lässt sich das WLAN nicht mit einem Neustart der Dienste reaktivieren? Es muss immer ein kompletter Reboot her.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

LuckyDay

Ich hatte mal kurz nach deinem Kernel gesucht

Warum gehst du überhauft auf die ungetesteten VorserienKernels?

https://github.com/raspberrypi/linux/issues/2453

Felix_86

Zitat von: fhem-hm-knecht am 26 Juli 2018, 15:35:16
Ich hatte mal kurz nach deinem Kernel gesucht

Warum gehst du überhauft auf die ungetesteten VorserienKernels?

https://github.com/raspberrypi/linux/issues/2453
Gute Frage, das wusste ich nicht.
Er hat mir diese Version im Rahmen des rpi-update runtergeladen und installiert. Ich dachte es sei die letzte stabile Version.

Was wäre denn dann die letzte getestete und freigegebene Version? Etwa die steinalte 4.9.35?
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

Otto123

Ich kann es Dir nicht sagen. Alles nur Vermutung. Bei mir stieg das Wlan einfach innerhalb 24 h bis 3 Tagen aus. Dann kam es manchmal wieder (es war eine ZeroW Testmaschine) oder blieb weg. Es half nur Stromlos machen am Pi ...
An der Maschine hab ich nichts geändert nur den Wlan Accesspoint und es lief monatelang stabil. Probier es einfach wenn Du kannst.

Schau doch mal ins /var/log/syslog bzgl. wlan. Was da so abgeht und wie groß es ist. Mir wurde damals schwindlig  :o
Als Hausnummer: mein syslog auf dem zerow hatte gestern 164 Zeilen und 15 kByte, das vom Pi3 hat 42 Zeilen und 4kByte

BTW: rpi-update habe ich mir irgendwann abgewöhnt. Ich nehme nur noch offizielle releases und mache manchmal apt-get upgrade.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

hsepm

#13
Zitat von: Felix_K am 26 Juli 2018, 14:42:35
...
Kabel nicht möglich
...

Evtl. hilft ja sowas:

TP-Link TL-WA860RE WLAN Repeater mit Frontsteckdose (300 Mbit/s, WLAN Verstärker, integrierte Steckdose, 1 LAN Port, App Steuerung, kompatibel zu allen gängigen WLAN Geräten) - Preis so zwischen 20 und 30 EURO schwankend.

Raspi LAN-Kabel rein und WLAN-Probleme vergessen.

Meine Erfahrung:

Am LAN-Anschluss hängt mein Arduino zur Heizungssteuerung und ich habe schon vergessen, wo der installiert ist.
Der TP-Link TL dient im Keller als WLAN-Repeater einer Fritzbox und deckt nebenbei noch den Garten mit ab.

Gruß,
Holger

Wernieman

Freunde mit seeeehr viel Linux-Kentnisse haben sich auch schon daran die Zähne ausgebissen. Warum gerade die Kombi Fritz/P so schlecht geht .....

Wenn Du die Netzwerdienste rebootest .. geht es dann?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Felix_86

Zitat von: Wernieman am 26 Juli 2018, 19:30:04
Freunde mit seeeehr viel Linux-Kentnisse haben sich auch schon daran die Zähne ausgebissen. Warum gerade die Kombi Fritz/P so schlecht geht .....

Wenn Du die Netzwerdienste rebootest .. geht es dann?
Nein, mit dem Restart diverser Dienste (sudo ifdown wlan0 / sudo ifup wlan0, service networking restart, sudo systemctl restart dhcpcd, sudo dhclient -r wlan0 / sudo dhclient -v wlan0) kommt das wlan0 Interface nicht zurück. Es ist immer ein Reboot des gesamten Pi erforderlich, wobei der Shutdown-Vorgang 5 Minuten bei "plymouth-reboot.service" verweilt bevor der Pi dann wirklich unten ist und neu startet.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

Wernieman

Du könntest auch probieren, das WLAN modul (den "Treiber") rauszuverfen (rmmod) und iweder zu laden (modprobe).

Nur wie schon gesagt, kenne auch exte Kracks, die sich daran ausgebissen haben...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Dr. Boris Neubert

Hallo,

mein einer Raspberry Pi 3 verliert auch ab und an die Verbindung. Der Stromsparmodus des WLAN-Treibers ist aus. Ich behelfe mir mit folgendem Skript, welches ich von cron alle 5 Minuten ausführen lasse. Das funktioniert bei mir.

Viele Grüße
Boris

#!/bin/bash

# vi /etc/crontab
# */5 * * * *     root    /home/pi/scripts/checkwifi.sh >> /dev/null 2>&1

DEBUG=0
DATE=`date "+%Y-%m-%d %H:%M:%S"`
IF=wlan0
WLAN=/sys/class/net/$IF
CARRIER=$WLAN/carrier

if [ ! -d $WLAN ] || [ $(cat $CARRIER) -eq 0 ]; then
  logger "$DATE: No network connection, restarting $IF"
  if [ -d $WLAN ]; then
        /sbin/ifdown $IF
        sleep 5
  fi
  /sbin/ifup --force $IF
  sleep 15
  echo $DATE | mail -s "DeinHostname lost network connection" -a "From: absender@example.com" empfaenger@example.com
  if [ ! -d $WLAN ] || [ $(cat $CARRIER) -eq 0 ]; then
        logger "$DATE: Still no network connection, rebooting"
        reboot                                                                                                                                                                     
  fi                                                                                                                                                                               
else                                                                                                                                                                               
  logger "$DATE: wlan0 carrier detected."                                                                                                                                           
  if [ $DEBUG -gt 0 ]; then                                                                                                                                                         
        echo $DATE | mail -s "DeinHostname is alive" -a "From: absender@example.com" empfaenger@example.com                         
  fi                                                                                                                                                                               
fi                                                                                                                                                                                 
exit 0                                                                                                                                                                             
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

Zitat von: Felix_K am 27 Juli 2018, 14:32:55
wobei der Shutdown-Vorgang 5 Minuten bei "plymouth-reboot.service" verweilt

Und was hindert Dich daran, plymouth komplett von Deinem Raspi zu entfernen? Brauchen tut das eigentlich niemand...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Felix_86

Zitat von: Dr. Boris Neubert am 30 Juli 2018, 18:17:15
Hallo,

mein einer Raspberry Pi 3 verliert auch ab und an die Verbindung. Der Stromsparmodus des WLAN-Treibers ist aus. Ich behelfe mir mit folgendem Skript, welches ich von cron alle 5 Minuten ausführen lasse. Das funktioniert bei mir.

Viele Grüße
Boris
Vielen Dank dafür. Ein Script zur Überwachung habe ich mir auch gebaut. Da ein ifdown / ifup, sowie der Neustart diverser Dienste und Prozesse keinen Erfolg zeigt, wenn das wlan0 Interface mal weg ist, würde hier wohl immer der finale Reboot greifen.
Diesen führe ich aktuell per FHEM AT in Abhängigkeit der Präsenz der FritzBox aus. Total unschön, aber damit läuft es größtenteils.

Aktuell bastel ich an der Antwort von Wernieman mit rmmod und modprobe um den Treiber neu zu laden. Da der WLAN Verlust aber selten dann auftritt, wenn ich davor sitze und mal Zeit / Lust zum Debuggen habe, zieht sich das Thema......


Zitat von: betateilchen am 31 Juli 2018, 09:11:28
Und was hindert Dich daran, plymouth komplett von Deinem Raspi zu entfernen? Brauchen tut das eigentlich niemand...
Danke, guter Einwand.
Ich glaube allerdings nicht, dass plymouth das Problem selbst ist, denn wenn der Raspberry eine WLAN Verbindung hat / das wlan0 Interface vorhanden ist, ist ein kompletter Reboot in 40 Sekunden erledigt. "plymouth-reboot.service" zeigt mir nur die Auswirkung auf den Reboot, wenn die WLAN Verbindung / das wlan0 Interface nicht vorhanden sind.  Die Ursache liegt aber schon viel früher am Verlust des WLAN / wlan0 Interface.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

Wuppi68

mal ne Idee zum testen ...

lege mal ne Bridge mit dem WLAN Interface an (https://wiki.ubuntuusers.de/Netzwerkbrücke/)

wenn die Bridge dann "oben" bleibt sollte es auch mit dem shutdown schneller klappen ;-)
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Felix_86

Kurze (finale) Rückmeldung von mir zu diesem Thema.

Der Pi läuft nun seit fast 10 Tagen durch, ohne Neustart und ohne WLAN Verlust.

Ich bin der Antwort von fhem-hm-knecht nachgegangen und habe ein Downgrade des Kernels auf Version 4.9.35 durchgeführt. Damit läuft die WLAN Verbindung deutlich stabiler.
Mit den zuvor vorgenommenen Änderungen am WLAN Power Management habe ich nun tagsüber überhaupt keine (spürbaren) WLAN Abbrüche mehr, selbst mit der FritzBox nicht.

Darüber hinaus habe ich das Script von Dr. Boris Neubert um eine weitere Prüfung ergänzt und ein modprobe -r brcmfmac / modprobe brcmfmac mit rfkill block 0 / rfkill unblock 0 eingebaut. Das Script läuft nun allmorgendlich, um bei einem WLAN Verlust in der Nacht einzugreifen. In den letzten 7 Tagen hat das Script nicht einmal eingegriffen. D.h. selbst bei abgeschalteter FritzBox in der Nacht wird die WLAN Verbindung nach Start der FritzBox wieder aufgebaut.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

Amenophis86

Dann poste doch mal dein Script für die Nachwelt und erkläre bitte, warum du es so verändert hast. Habe ich nicht ganz verstanden :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Felix_86

Mein Script sieht nun wie folgt aus:


#!/bin/sh

# vi /etc/crontab
# */5 * * * *     root    /home/pi/Daten/Scripte/check-wlan.sh >> /dev/null 2>&1

DEBUG=0
DATE=`date "+%Y-%m-%d %H:%M:%S"`
IF=wlan0
WLAN=/sys/class/net/$IF
CARRIER=$WLAN/carrier
MAILCOMMAND=/home/pi/Daten/Scripte/sendmail.sh
LOG=/home/pi/sharedfolder/check-wlan-`date +"%Y"`-`date +"%m"`.log

if [ ! -d $WLAN ] || [ $(cat $CARRIER) -eq 0 ]; then
  sudo echo "$DATE - No network connection, restarting $IF" >> $LOG
 
  if [ -d $WLAN ]; then
        sudo /sbin/ifdown $IF
        sleep 5
  sudo /sbin/ifup --force $IF
  sleep 15
  fi

  if [ ! -d $WLAN ] || [ $(cat $CARRIER) -eq 0 ]; then
  sudo echo "$DATE - Still no network connection, resetting driver" >> $LOG
 
   if [ -d $WLAN ]; then
         sudo modprobe -r brcmfmac
         sleep 2
      sudo modprobe brcmfmac
  sleep 2
         sudo rfkill block 0
  sleep 2
         sudo rfkill unblock 0
  sleep 2
         sudo /sbin/ifdown $IF
         sleep 2
         sudo /sbin/ifup --force wlan0
  sleep 15
   fi

  fi

  if [ $DEBUG -gt 0 ]; then
echo $DATE | $MAILCOMMAND empfänger@domain.TLD "Pi lost network connection but restarted" "$DATE"
  fi

  if [ ! -d $WLAN ] || [ $(cat $CARRIER) -eq 0 ]; then
  sudo echo "$DATE - Still no network connection, rebooting Pi" >> $LOG
        reboot
  fi


else
  sudo echo "$DATE - wlan0 carrier detected" >> $LOG
  if [ $DEBUG -gt 0 ]; then
echo $DATE | $MAILCOMMAND empfänger@domain.TLD "Pi is alive" "$DATE"
  fi
fi

exit 0


Im Original von Dr. Boris Neubert wird nach dem "restarting wlan0" (ifdown / ifup) als nächster Schritt ein Reboot des Pi's durchgeführt. Da ein "restarting wlan0" (ifdown / ifup) in meinem Fall häufig nicht möglich ist / war, da das wlan0 Interface nicht vorhanden ist / war, wurde immer ein Reboot durchgeführt.
Diesen Reboot versuche ich nun zu verhindern, indem ein "resetting driver" (modprobe -r brcmfmac / modprobe brcmfmac und rfkill block 0 / rfkill unblock 0) ausgeführt wird, bevor es zum finalen Reboot des Pi kommt.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS