Hallo, ich hatte vor einiger Zeit einen Post zum Thema "Selbstbau ESP Antenne" (Beitrag "DIY Antenne für WLAN bzw. ESP/Arduiino") abgesetzt, weil ich ein Problem mit einem ESP als Webserver hatte und ich dessen Ursache zunächst mit einer schlechten Signalstärke/Qualität in Verbindung brachte. Nach viel viel Analyse und Try & Error liegt die Ursache aber offenbar am Basisrouter (Fritz Box 7530). Ein ESP8266 wird als Webserver im Hausnetz betrieben, er lässt sich problemlos mit dem Router verbinden und im Fritz-Monitor auch stets als aktiv/verbunden angezeigt, per PING auch ansprechbar -ABER: wenn sowohl ESP/Webserver als auch die Clients (Browser vom PC/Handy) mit dem ESP kommunizieren wollen antwortet der ESP nicht (obwohl er nachweislich mit dem Router verbunden ist und TCP Verbindung vom PC/Handy zum ESP aufgebaut ist). Die Probleme tauchen sporadisch auf, in erster Linie bei längerem Betrieb des Webservers. Wireshark-Logging der WLAN Aktivitäten haben das final bestätigt, aber die eigentliche Ursache dieses Verhaltens nicht ausfindig machen können. Potenzielle Ursachen wie andere (störende) WLAN Netze, weitere ESPs im Netz, instabile ESP Anschlussspannung oder auch die zunächst angenommene schwache Signalstärke wurden schrittweise mit viel Aufwand und Versuchen ausgeschlossen. Nun das Seltsame: Melde ich den ESP an einem Repeater (FritzBox im Repeaterbetrieb) an oder den ESP am Basisrouter aber den PC oder Handy am Repeater, so klappt die Kommunikation tadellos, ohne Probleme auch im Langzeitbetrieb (über mehrere Tage hinweg). Unter dieser Bedingung ist das Problem nicht reproduzierbar. Die WLAN Kommunikation ist beim Basisrouter unter den angebundenen WLAN Geräten untereinander erlaubt (FritzBox Konfiguration). Die Kommunikation erfolgt auch direkt über die feste IP Adresse des ESP im Hausnetz, also mDNS Probleme können auch nicht die Ursache sein. Signalstärke/qualität sind es wie oben erwähnt auch nicht, da die Verbindung zum Repeater (egal ob ESP am Hauptrouter angemeldet oder PC/Handy) eine geringere Signalstärke (-80dBm versus -60dBm) aufweist als die zum Basisrouter (-60dBm). Habe nun alles mögliche ausprobiert und analysiert, die Ursache, warum das Ganze nur über den Repeater läuft und nicht stabil (=stets funktionstüchtig), wenn alle Beteiligten am Basisrouter angeschlossen sind, bleibt mir im Dunkeln...:-( Hat irgendjemand eine Idee?
Bernd Laura schrieb: > Woran kann das liegen ? Bernd Laura schrieb: > Nach viel viel Analyse und Try & Error liegt die Ursache aber offenbar > am Basisrouter (Fritz Box 7530) Das war einfach.
Alexander schrieb: > Bernd Laura schrieb: >> Woran kann das liegen ? > > Bernd Laura schrieb: >> Nach viel viel Analyse und Try & Error liegt die Ursache aber offenbar >> am Basisrouter (Fritz Box 7530) > > Das war einfach. Alex, das war hoffentlich nur ironisch gemeint... für mich mittlerweile zum Verzweifeln, aber mit dem, was oben beschrieben ist zumindest mal ein Workaround, ohne zu wissen, wo die eigentliche Ursache liegt bzw. warum es über den Basisrouter alleine nicht klappt (obwohl ping stets klappt, sogar "CURL -v IP Adresse" klappt stets solange der HTTP-Header nicht zu gross ist)
Du schreibst: >> Wireshark-Logging der WLAN Aktivitäten >> haben das final bestätigt, aber die eigentliche Ursache dieses >> Verhaltens nicht ausfindig machen können. Kannst Du die Aussage erklären? Warum sieht man in dem Log die Ursache nicht? Es sollte doch zumindest sichtbar sein, welcher Teilnehmer sich nicht so verhält wie erwartet.
Angehängte Dateien:
Thomas F. schrieb: > Du schreibst: >>> Wireshark-Logging der WLAN Aktivitäten >>> haben das final bestätigt, aber die eigentliche Ursache dieses >>> Verhaltens nicht ausfindig machen können. > > Kannst Du die Aussage erklären? Warum sieht man in dem Log die Ursache > nicht? Es sollte doch zumindest sichtbar sein, welcher Teilnehmer sich > nicht so verhält wie erwartet. Hab ein Wireshark Trace, bei dem die Kommunikation nur über den Basisrouter erfolgt, d.h. alle Beteiligten an der Basis angemeldet, mal angehängt. Die IP xx.48 ist der PC, die IP xx.37 ist der ESP. Man sieht, dass die TCP Verbindung aufgebaut wird, der PC (via Browser) an den ESP eine Anfrage sendet, aber der ESP nichts zurück sendet. Es funktioniert dann mit keinem Browser (Chrome, Firefox, Microsoft...), jedoch stets mit "CURL xx.37", und der PING xx.37 funktioniert sowieso stets nach Anmeldung des ESP am Router. Der Browser auf Client Seite scheint eine Rolle zu spielen (Cash refresh etc.) hat alles nichts gebracht, oft geht es auch schon direkt nach der Anmeldung des ESP am Basisrouter schon nicht, wenn ESP und PC am Basisrouter hängen.
:
Bearbeitet durch User
Das Problem ist also die Kommunikation von WLAN-Clients untereinander während die Kommunikation WLAN-Client mit dem Accesspoint funktioniert. Du kannst ja mal probieren den PC mit Ethernet-Kabel mit dem Accesspoint verbinden, vermutlich wird dann der Zugriff auf den ESP8266 auch funktionieren. Ursache könnten z.B. unterschiedliche WLAN-Sicherheitseinstellungen zwischen den Clients sein oder grenzwertige bis fehlerhafte Implementation der WLAN-Standards im ESP8266. Die Lösung dürfte sein auf dem Accesspoint dafür zu sorgen dass die WLAN-Clients nicht mehr direkt untereinander kommunizieren dürfen, sondern immer ausschließlich über den Accesspoint. Keine Ahnung ob der WLAN-Accesspoint einer Fritzbox diese Einstellmöglichkeit bietet. Bei OpenWRT z.B. ist es die Option "isolate" des wifi-iface.
Gerd E. schrieb: > > Die Lösung dürfte sein auf dem Accesspoint dafür zu sorgen dass die > WLAN-Clients nicht mehr direkt untereinander kommunizieren dürfen, > sondern immer ausschließlich über den Accesspoint. > > Keine Ahnung ob der WLAN-Accesspoint einer Fritzbox diese > Einstellmöglichkeit bietet. Bei OpenWRT z.B. ist es die Option "isolate" > des wifi-iface. Die FritzBox kann das konfigurieren. Wie beschrieben ist das Feature, dass die Kommunikation unter den WLAN Endpunkten/Teilnehmern erlaubt ist, aktiviert (Default Einstellung). Wenn ich es deaktiviere, geht die Kommunikation über den Basisrouter allein nie, nicht nur sporadisch nicht, sondern nie - was ja auch genau dieses Flag in der Fritz-Konfig aussagt. Insofern verstehe ich nicht, warum du es deaktivieren willst. Aber wenn ich den PC über LAN betreibe, funktioniert es auch - es ist dann auch ein Weg, die WLAN Kommunikation alleinig über den Basisrouter zu umgehen. Wenn ein Teilnehmer nicht am WLAN Basisrouter angemeldet ist, funktioniert es.
Gerd E. schrieb: > Das Problem ist also die Kommunikation von WLAN-Clients untereinander > während die Kommunikation WLAN-Client mit dem Accesspoint funktioniert. > Es ist nur EIN Client (PC oder Handy mit Browser) im Spiel, also Client (PC/Handy) mit Browser kommuniziert mit WebServer - und je nachdem wo die beiden hängen (Basis versus Repeater/Lan) funktioniert es nicht (stabil, kontinuierlich )
Anderer Access Point klingt auch nach verändertem Standort des ESP. Ist die Spannungsversorgung des ESP an beiden Orten exakt gleich, auch gleiches Netzteil und Leitungslänge? 2. Hast du mal während der ESP noch ansprechbar ist, nach memory leaks geschaut? Evtl. macht sich eins nur bei bestimmten Netzwerkumgebungen (z.b. gelegentliche reconnects oder ausbleiben eben solcher) bemerkbar.
:
Bearbeitet durch User
Diese Fritzboxen genauergesagt dieses Frickel OS mit vernachlässigtem 2.4GHz WiFi sind der größte Dreck auf Erden, kontinuierlich verschlimmbessert von Update zu Update seit 10 Jahren zu nichts mehr zu gebrauchen.
Flip B. schrieb: > Anderer Access Point klingt auch nach verändertem Standort des ESP. Ist > die Spannungsversorgung des ESP an beiden Orten exakt gleich, auch > gleiches Netzteil und Leitungslänge? Es gibt auch nur EIN ESP8266 als Web Server, dessen Standort fest ist und lediglich an Basisstation oder Repeater beim Hochfahren/Starten angemeldet werden kann (ähnlich dem PC als Client) > 2. Hast du mal während der ESP noch ansprechbar ist, nach memory leaks > geschaut? Evtl. macht sich eins nur bei bestimmten Netzwerkumgebungen > (z.b. gelegentliche reconnects oder ausbleiben eben solcher) bemerkbar. Ja, hab mir alle Mem Daten und Fragmentierungen im Arduino Monitor anzeigen lassen, alles tief grün, Fragmentierung gerade mal 1%; Fehlverhalten scheint auch unabhängig von Zahl der Connections zu sein... lediglich die Größe des HTTP Headers im Browser scheint eine Rolle zu spielen, wenn dieser eine bestimmte Größe überschreitet schlägt es fehl, aber wie gesagt nicht, wenn einer der Teilnehmer am Repeater angeschlossen ist
Alexander schrieb: > Diese Fritzboxen genauergesagt dieses Frickel OS mit vernachlässigtem > 2.4GHz WiFi sind der größte Dreck auf Erden, kontinuierlich > verschlimmbessert von Update zu Update seit 10 Jahren zu nichts mehr zu > gebrauchen. Stimme zu, 7530 wird halt von 1&1 zur Verfügung gestellt , der Vorgänger 7412 war durchaus stabiler, den hab ich als Repeater im Einsatz... weiss aber nicht, ob der 7412 als Basisstation ähnliche Probleme macht und was genau die Ursache an dieser Konstellation ist ...
Bernd Laura schrieb: > Gerd E. schrieb: >> >> Die Lösung dürfte sein auf dem Accesspoint dafür zu sorgen dass die >> WLAN-Clients nicht mehr direkt untereinander kommunizieren dürfen, >> sondern immer ausschließlich über den Accesspoint. > > Die FritzBox kann das konfigurieren. Wie beschrieben ist das Feature, > dass die Kommunikation unter den WLAN Endpunkten/Teilnehmern erlaubt > ist, aktiviert (Default Einstellung). Wenn ich es deaktiviere, geht die > Kommunikation über den Basisrouter allein nie, nicht nur sporadisch > nicht, sondern nie - was ja auch genau dieses Flag in der Fritz-Konfig > aussagt. Insofern verstehe ich nicht, warum du es deaktivieren willst. Ich glaube Du hast mich Missverstanden. Es geht nicht darum die Kommunikation der WLAN-Clients untereinander komplett zu verbieten, sondern darum, dass Sie das nicht mehr direkt dürfen. Sie sollen ihre Kommunikation untereinander immer erst zum Accesspoint schicken und der schickt sie dann an den Empfänger weiter. Eben nicht mehr direkt, sondern immer über Bande. Das sollte eine separate Einstellung sein zu der die die Kommunikation untereinander komplett verbietet.
Schade dass der Zeitstempel im Wireshark-Screenshot fehlt. Aber man sieht, dass nach dem http-get des PC der ESP nicht antwortet, auch nach sechs Wiederholungen nicht. Abgestürzt ist der sicher nicht, der beendet die bestehende TCP-Verbindung anschließend ganz regulär mit FIN, ACK. Allerdings mit veralteter Sequence-Number, als hätte er die Datenpakete vom PC nicht mehr gesehen. Kenne mich nicht mit ESPs aus, vermute aber den Fehler in dessen Konfiguration.
:
Bearbeitet durch User
Es wurden doch kürzlich umfangreiche Firmwareupdates für viele Fritzboxen angekündigt, gerade für die 7530(AX). Sind zwar vorerst nur "Laborversionen", könnte man aber mal testen. https://www.pcwelt.de/article/3034468/11-fritzboxen-bekommen-firmware-update-das-steckt-alles-drin.html
Gerd E. schrieb: > Sie sollen ihre Kommunikation untereinander immer erst zum Accesspoint > schicken und der schickt sie dann an den Empfänger weiter. So funktioniert das im WLAN immer. Deswegen hat der Paketheader drei MAC-Adressen. Kommunikation zwischen Clients gibt es nur im AdHoc-Modus, in den sich die Frizbox nicht versetzen lässt.
Habe ein ähnliches Problem mit einem PiPico2. Der PiPico2 hängt an einer FritzBox 7690. Der Webserver läuft sporadisch ein paar Tage(oder nur ein paar Stunden) ohne Probleme. Irgendwann wird er zwar noch angezeigt in den Netzwerkeinstellungen der FritzBox. Will man im Browser den PiPico2 aufrufen kommt nur ERR_CONNECTION_REFUSED Auf dem PiPico2 läuft Micropython. Das Python Programm an sich läuft weiter. Wollte es nun mal auf einem ESP32-C6 ausprobieren. Aber das Problem von dir hört sich ähnlich an...
Karls Q. schrieb: > Es wurden doch kürzlich umfangreiche Firmwareupdates für viele > Fritzboxen angekündigt, gerade für die 7530(AX). Sind zwar vorerst nur > "Laborversionen", könnte man aber mal testen. Na ja, solch grundlegende WLAN-Funktionalitäten brauchen keine bleeding edge Labor-Firmwares. Im anderen Thread steht: Bernd Laura schrieb: > Es ist so, dass ich den ESP als WLAN gesteuerter Schalter nutze, der > über Handy angesteuert wird. Handy kommuniziert mit Router über WLAN > Netz, Router mit ESP. Sind Router und ESP im gleichen Raum, funktioniert > es tadellos. In getrennten Räumen bestenfalls ab und zu mal sporadisch, > meistens gar nicht. Alternativ habe ich zur Probe auch mal eine alte FB > als Repeater im Nachbarraum direkt neben dem ESP eingesetzt, dann > funktioniert es auch tadellos. Das liegt nicht an der Fitzbox. Oliver
Peter Z. schrieb: > Habe ein ähnliches Problem mit einem PiPico2. > > Der PiPico2 hängt an einer FritzBox 7690. > Der Webserver läuft sporadisch ein paar Tage(oder nur ein paar Stunden) > ohne Probleme. > > Irgendwann wird er zwar noch angezeigt in den Netzwerkeinstellungen > der FritzBox. Will man im Browser den PiPico2 aufrufen kommt nur > ERR_CONNECTION_REFUSED > > Auf dem PiPico2 läuft Micropython. > Das Python Programm an sich läuft weiter. > > Wollte es nun mal auf einem ESP32-C6 ausprobieren. > Aber das Problem von dir hört sich ähnlich an... Ja, sieht ähnlich aus. Aber bei mir kommt am Browser nach dem HTTP Request an den ESP nichts zurück, bei dir scheint was zurückzukommen, wird aber abgelehnt. Wenn möglich, versuch mal bei dir , wenn der Fehlerfall aufritt einen CURL Befehl vom PC an die IP des PICO abzusetzen (z.B CURL -v IP_PICO); der funktioniert bei mir immer.
Hatte jetzt noch eine alte FritzBox als Basis konfiguriert und den ESP sowie den PC über WLAN daran angemeldet. Funktioniert bislang ohne Probleme; diese Basisstation läuft aber ohne Internetanschluss und ohne jegliche weitere Geräte (Telefon, Anrufbeantworter) - einfach nur als WLAN Router separat zu dem Problemrouter 7530. Defekt ist der 7530 sicher nicht zumal er schon 2 mal wegen anderer potenzieller Probleme von 1&1 ausgetauscht wurde. Mir fehlen jetzt echt noch die Ideen und Tools weitere Analysen anzustellen; Work Around über Repeater gut und schön, aber ohne den genauen Grund zu kennen, unbefriedigend :-( Völlig im Dunkeln: Was macht der Router mit dem HTTP Header des Client (Browser), da es beim Problemrouter ja mit PING/CURL und minimierten HTTP Header funktioniert aber nicht (immer) mit den Standard-Header des Browsers?? Was kann dabei (sporadisch) schief gehen, dass der ESP unter Umständen gar keine Info mehr bekommt - beim IDE Monitoring wurde der Handler des Webservers/ESP gar nicht aufgerufen, wenn es zum Fehlerfall kommt. Könnte bedeuten, der ESP wird vom Basis-Router erst gar nicht aufgerufen, wenn nicht ein Repeater zwischengeschaltet ist... Aber die Header des Browsers sind immer identisch, ob es fehl schlägt oder nicht; nur wenn ich den Header "künstlich" minimiere/manipuliere/abspecke, dann funktioniert es auch am Problemrouter (käme dann dem CURL Aufruf näher, der ja mit minimalem Header arbeitet)
:
Bearbeitet durch User
Klaus schrieb: > Wulf D. schrieb: >> Schade dass der Zeitstempel im Wireshark-Screenshot fehlt. > > Guck nochmal genau. Da ist nichts, abgeschnitten. Wie auch immer, die PC http get werden laut wireshark Screenshot nicht vom ESP beantwortet. Kannst du nicht mal auf dem ESP nachsehen (debug log, rs232-Konsole oder ähnliches) warum der die Pakete nicht mag? Irgendwas muss der Antworten, und sei es nur ein TCP ACK.
:
Bearbeitet durch User
Bernd Laura schrieb: > nur wenn ich den Header "künstlich" minimiere/manipuliere/abspecke, dann > funktioniert es auch am Problemrouter Ich habe schon Fehler in Software gesehen, da wurden Pakete von 257 Bytes verworfen, alle andere gingen durch. Bezogen auf Fritzbox: Während Corona bin ich fast verzweifelt, weil mit meinem tollen 1GBit-Cable-Anschluss so gut wie nie BigBlueButton-Konferenzen fürs Homeschooling gingen. Monate später hat sich dann rausgestellt, dass es ein FW-Problem der Fritzbox war...
Klaus schrieb: > Bezogen auf Fritzbox: Während Corona bin ich fast verzweifelt, weil mit > meinem tollen 1GBit-Cable-Anschluss so gut wie nie > BigBlueButton-Konferenzen fürs Homeschooling gingen. > Monate später hat sich dann rausgestellt, dass es ein FW-Problem der > Fritzbox war... Nur hatten damals alle FRITZboxen über (Vodafone?-) Kabel das Problem. Hier im Thread siehts ja eher nach einem Einzelfall aus. Oliver
Oliver S. schrieb: > Hier im Thread siehts ja eher nach einem Einzelfall aus. Jein. Ein Webserver auf einem WLAN-Client ist halt nichts, was Ottonormal-User betreibt. Insofern könnte das Problem durchaus auch eines der Fritzbox sein, aber es ist nur noch niemandem aufgefallen.
:
Bearbeitet durch User
Ein ESP mit Server drauf sollte es aber doch schon mal irgendwo gegeben haben. Oliver
:
Bearbeitet durch User
Natürlich. Aber um mal bei dem Beispiel zu bleiben: Ob eine http-Anfrage eines anderen WLAN-CLients mit genau 483 Bytes wirklich auch so vorkommt, wer weiß das schon. Hier ist der Thread mit dem damaligen UDP Fehler, ein einziges Byte im INHALT machte da den Unterschied: https://www.ip-phone-forum.de/threads/kabel-fritzbox-blockiert-gewisse-udp-pakete.308076/ @Bernd: Hast Du mal versucht, bei der 7530 die Paketbeschleunigung auszuschalten?
:
Bearbeitet durch User
Klaus schrieb: > @Bernd: Hast Du mal versucht, bei der 7530 die Paketbeschleunigung > auszuschalten? Nein, zumindest nicht bewusst. Kannst du mir sagen, wie das geht - irgendwo eine Konfiguration, die mir nicht bekannt ist?
Bernd Laura schrieb: > Klaus schrieb: > >> @Bernd: Hast Du mal versucht, bei der 7530 die Paketbeschleunigung >> auszuschalten? > > Nein, zumindest nicht bewusst. Kannst du mir sagen, wie das geht - > irgendwo eine Konfiguration, die mir nicht bekannt ist? Hab's gefunden, Layer 2 Beschleunigung war aber schon deaktiviert
Ich kann beisteuern, dass ich an einer 7530 (aktuelle Firmware: 8.21) bestimmt 10 ESP8266 laufen habe, dazu noch einige ESP32, alles ohne Probleme. Alles mit DHCP. Ich hatte mal Probleme, als für einige Wochen eine IP im Netz doppelt war (falsche statische IP eingetragen). Da war der Zugriff Glückssache. Da die Liste der Netzwerkgeräte in der Fritzbox ja recht lang war, ist mir das nicht so schnell aufgefallen.
Ansonsten ... Fritzboxen haben eine "Kindersperre", mit der sie bestimmte Funktionalitäten einzelner Clients unterbinden können. In deren Liste sollte man auch mal nachsehen, wenn es zu so seltsamen Phänomenen kommt. Davon abgesehen wird die 7530 aber noch mit aktueller Software versorgt, allzu arge Böcke sollten da nicht drin sein. Wobei: Ich kenne eine 7530, die alle paar Wochen mal neu gestartet werden muss, da sonst das über sie laufende VPN immer unzuverlässiger wird, bis hin zum Ausbleiben simpler Ping-Requests (nur jeder dritte oder so wird beantwortet). Und das beim gleichen ISP an beiden Enden (Telekom, Glasfaser) und perfekter störungsfreier Internetverbindung.
Xxx X. schrieb: > Ich kann beisteuern, dass ich an einer 7530 (aktuelle Firmware: 8.21) > bestimmt 10 ESP8266 laufen habe, dazu noch einige ESP32, alles ohne > Probleme. Alles mit DHCP. > Ich hatte mal Probleme, als für einige Wochen eine IP im Netz doppelt > war (falsche statische IP eingetragen). Da war der Zugriff Glückssache. > Da die Liste der Netzwerkgeräte in der Fritzbox ja recht lang war, ist > mir das nicht so schnell aufgefallen. Hast du die ESPs alle als Client laufen oder auch einen als Webserver darunter, der HTML Code zum Client(Browser) sendet. Mit dem puren Betrieb von ESPs am Router als Client habe ich auch keine Probleme. Es geht hier speziell um den Fall, dass man einen ESP als WebServer im Spiel hat und diesen über Browser anspricht.
Bernd Laura schrieb: > ESP als WebServer Welchen denn ? Selber kompiliert ? Habe zig ESP mit Tasmota am laufen ohne Probleme. Schon mal eine andere Firmware ausgetestet ?
Alle ESP8266 und ESP32 machen hier einen Webserver auf und ich greife per Browser problemlos zu (also nach dem Schema http://xxxxx.fritz.box).
Chris K. schrieb: > Bernd Laura schrieb: >> ESP als WebServer > > Welchen denn ? Selber kompiliert ? > > Habe zig ESP mit Tasmota am laufen ohne Probleme. > > Schon mal eine andere Firmware ausgetestet ? Verschiedene Type, ESP8266-01 und D1 Mini, Nutzung von Standardlibs (synchrone und asynchrone Kommunikation ausprobiert); Tasmota habe ich auch problemlos am Laufen, aber die laufen über Repeater
:
Bearbeitet durch User
Xxx X. schrieb: > Alle ESP8266 und ESP32 machen hier einen Webserver auf und ich greife > per Browser problemlos zu (also nach dem Schema http://xxxxx.fritz.box). Bin mir nicht sicher, ob wir hier vom gleichen reden. Welche Libs nutzt du denn für den Webserver oder hast du einfach Tasmota aufgespielt?
:
Bearbeitet durch User
Ich benutze Tasmota, und das hat auch einen Webserver am laufen. Also versuch mal eine andere FW z.B. Tasmota auf dem Problematischen Gerät. Wenn der Fehler dann nicht auftritt -> deine libs ....
Achso, bei mir sind das diverse "Steckdosen" und Ähnliches, wo überall ElecPow drauf läuft. Ist anders als Tasmota, aber eben auch problemlos. Ich würde an deiner Stelle auch erstmal andere Firmwares testen. Bevor ich die Fritzbox angeschafft habe, hatte ich mal eine "O2 Homebox". Das war ein Krampf! Da war offensichtlich der DHCP-Server kaputt. Bin froh, dass diese Zeiten vorbei sind.
Harald K. schrieb: > Ansonsten ... Fritzboxen haben eine "Kindersperre", mit der sie > bestimmte Funktionalitäten einzelner Clients unterbinden können. In > deren Liste sollte man auch mal nachsehen, wenn es zu so seltsamen > Phänomenen kommt. Danke für den Hinweis. Hatte ich tatsächlich gemacht, weil ich teils mit einem Sicherheitsproblem gerechnet hatte, aber kein Eintrag war gegeben. Und wenn, dann hätte ich auch erwartet, dass es für entsprechende GET Requests nie funktioniert und nicht nur sporadisch nicht. > Davon abgesehen wird die 7530 aber noch mit aktueller Software versorgt, > allzu arge Böcke sollten da nicht drin sein. > > Wobei: Ich kenne eine 7530, die alle paar Wochen mal neu gestartet > werden muss, da sonst das über sie laufende VPN immer unzuverlässiger > wird, bis hin zum Ausbleiben simpler Ping-Requests (nur jeder dritte > oder so wird beantwortet). Und das beim gleichen ISP an beiden Enden > (Telekom, Glasfaser) und perfekter störungsfreier Internetverbindung. Ein Durchstarten des Basisrouters hat übrigens in der Tat auch den Fehlerfall(Browser bekam immer ein Fehler "Server antwortet nicht") temporär beiseitigt - bis er dann wieder nach ein paar Minuten/Stunden auftritt. Ein Durchstarten des ESP hatte dagegen nie eine positive Wirkung auf den Effekt.
Gerd E. schrieb: > Es geht nicht darum die > Kommunikation der WLAN-Clients untereinander komplett zu verbieten, > sondern darum, dass Sie das nicht mehr direkt dürfen. Sie sollen ihre > Kommunikation untereinander immer erst zum Accesspoint schicken und der > schickt sie dann an den Empfänger weiter. Eben nicht mehr direkt, > sondern immer über Bande. Phantasierst Du oder hast Du das schon real umgesetzt? Ich habe hier die lokale Kommunikation gesperrt mit dem Ergebnis, dass zwei WLAN im selben Netz es nicht mehr können, klingt ja gewollt. Wenn doch, Dein "über Bande", erfordert dann, an allen WLAN-Clients eine Route zu addieren, Standradgateway des eigenen Netzes. Bernd Laura schrieb: > Ein Durchstarten des Basisrouters hat übrigens in der Tat auch den > Fehlerfall(Browser bekam immer ein Fehler "Server antwortet nicht") > temporär beiseitigt - bis er dann wieder nach ein paar Minuten/Stunden > auftritt. Dann schalte WLAN am Router ab und setze einen funktionierenden Accesspoint daneben, die Welt der Netzwerke besteht nicht nur aus Fritz.
Ich hab sowas ähnliches auch schon erlebt. Setup: 7590 als DSL router, 7530ax, verbunden über LAN, als Repeater. DHCP und andere Serverdienste über separaten Server im LAN. Ab und zu, nach längerer Zeit, bekamen die Tasmota Steckdosen (ESP8285) keine Adresse mehr über DHCP wenn sie versuchten sich über die Repeaterbox zu verbinden. Steckdose aus und einstecken und es ging wieder. Die Lösung dafür hab ich experimentell gefunden: auf dem DHCP server (dnsmasq) für die Steckdosen das flag "dhcp-broadcast" setzen. Anscheinend hat die repeater-Fritzbox manchmal das DHCPREPLY paket gefressen wenn das nicht broadcastet wurde. Hatte dazu auch ein Ticket bei AVM offen, die haben sich auch interessiert und versucht zu helfen, aber nach 4 Wochen war halt der Vorschlag "probiere es bitte mal mit dem internen dhcp der Fritzbox", wozu ich nicht bereit war. Dann, später, hatte ich anscheinend genau das hier geschilderte Problem: ping zu esp32 ging noch, connects auch (meist) aus dem LAN, aber (oft) nicht aus dem WLAN usw, curl auf eine beliebige Steckdose gab zwar einen connect, aber die Antwort kam nicht oder nur sehr verzögert. Da die Router-Fritzbox eh in den Keller umgezogen ist (Glasfaseranschluss) und dort für WLAN am dümmstmöglichen Platz sitzt, außerdem evtl vom Kondensatorproblem betroffen ist, habe ich deren WLAN abgeschaltet und das übernimmt nun ein mit openWRT betriebener DLINK COVR-X1860 (auch per LAN verbunden, gäste-WLAN per VLAN zugeliefert, an geeigneter Stelle aufgestellt). Seitdem gibt es diese Probleme nur noch sehr selten, und wenn es mal auftritt, dann reboote ich die 7530ax was dazu führt daß sich alle clients mal am DLINK anmelden bis die wieder da ist (Generell ist es so daß alle Geräte beide Accesspoints sehen, aber halt dann teilweise echt mit grenzwertigem Signal) und dann ist wieder für ein paar Monate Ruhe. Kann mich auch nicht mehr erinnern wann das zuletzt notwendig war. Hätte ich ein Standardsetup, würde ich einfach ein Ticket bei Fritz aufmachen, meiner Erfahrung nach sind die bei ordentlichen Problembeschreibungen durchaus interessiert das abzustellen und ihr Zeug zu verbessern. Aber bei meinem Bastelsetup kommen sie halt irgendwann (IMHO zu Recht) mit "Bitte einmal mit Standardeinstellungen testen", was für mich nun mal keine Option ist :-D
Bernd Laura schrieb: > Stimme zu, 7530 wird halt von 1&1 zur Verfügung gestellt Da hast Du schon das Problem.
Stefan S. schrieb: > Ich hab sowas ähnliches auch schon erlebt. > Setup: 7590 als DSL router, 7530ax, verbunden über LAN, als Repeater. > DHCP und andere Serverdienste über separaten Server im LAN. > > Vielen Dank Stefan für deine ausführliche Beschreibung!! Das sieht von den Symptomen her meinem Problem sehr ähnlich. Allerdings spielt in meinem Falle DHCP keine Rolle; ich habe jeden ESP als Webbrowser oder Client mit einer IP fest verdrahtet und steuere die einzelnen Endpunkt direkt per IP an, nicht über irgendeine Domäne - und aktuell auch nur intern, nicht über Internet (ich vermute, die Ansteuerung über Internet würde vielleicht sogar gehen - das muss ich mal noch testen). Sobald der 7530(AX) als Basisrouter mit einem PC bzw. Browser (direkt verbunden) mit dem ESP als Webserver (ebenfalls direkt mit dem Basisrouter verbunden) kommunizieren will, geht entweder von Anfang an oder nach einer gewissen Zeit (Minuten/Stunden) nichts mehr. Die Browser melden immer, dass sie keine Antwort bekommen, obgleich sowohl ein PING zum ESP als auch ein CURL (mit reduziertem HTTP Header im Vergleich zum HTTP Header des Browsers) sauber funktionieren. Und wenn es funktioniert, läuft es sogar mit verschiedenen und mehreren Browsern, die auf den gleichen ESP Endpunkt zugreifen, zur gleichen Zeit sogar.
:
Bearbeitet durch User
Bernd Laura schrieb: > Man sieht, > dass die TCP Verbindung aufgebaut wird, der PC (via Browser) an den ESP > eine Anfrage sendet, aber der ESP nichts zurück sendet. Es hilft Nix, aber da wirst du auf dem ESP mal ergründen müssen, was genau dem fehlt. Vielleicht bringt das dann mehr Erkenntnisse. Oliver
Oliver S. schrieb: > Es hilft Nix, aber da wirst du auf dem ESP mal ergründen müssen, was > genau dem fehlt. Vielleicht bringt das dann mehr Erkenntnisse. Du bist also sicher, dass das Paket beim ESP ankommt?
Bernd Laura schrieb: > Ein Durchstarten des Basisrouters hat übrigens in der Tat auch den > Fehlerfall(Browser bekam immer ein Fehler "Server antwortet nicht") > temporär beiseitigt - bis er dann wieder nach ein paar Minuten/Stunden > auftritt. Könntest Du bitte in beiden Situationen einen Wireshark-Log anfertigen? Brauchst den nicht aufbereiten, einfach hier rein posten. Klaus schrieb: > Oliver S. schrieb: >> Es hilft Nix, aber da wirst du auf dem ESP mal ergründen müssen, was >> genau dem fehlt. Vielleicht bringt das dann mehr Erkenntnisse. > > Du bist also sicher, dass das Paket beim ESP ankommt? Frage ich mich auch schon länger, leider mag Bernd Laura nicht auf dem ESP nachsehen.
Konntest Du mit einer eMail was anfangen? (WIFI_NONE_SLEEP, ARP Cache)
Angehängte Dateien:
Oliver S. schrieb: > Bernd Laura schrieb: >> Man sieht, >> dass die TCP Verbindung aufgebaut wird, der PC (via Browser) an den ESP >> eine Anfrage sendet, aber der ESP nichts zurück sendet. > > Es hilft Nix, aber da wirst du auf dem ESP mal ergründen müssen, was > genau dem fehlt. Vielleicht bringt das dann mehr Erkenntnisse. > > Oliver Anbei ein weiteres Wireshark Protokoll: beide Teilnehmer (Webserver/ESP mit IP x.37 + PC mit Browser mit IP x.48) hängen direkt am Basisrouter - Pakete 85 bis 96 zeigen ein funktionierende Kommunikation - Pakete ab 5068 zeigen ein Fehlschlagen, wenn der oder alle getesteten Browser eine Fehlermeldung bekommen, dass vom ESP nichts kommt Wenn ich in der "stabilen" Fehlersituation ein Neustart des ESP antriggere bleibt der Fehler bestehen; ein Wiederstart des Routers löst den Fehler auf. Das ist ein Argument aus meiner Sicht, dass der ESP bei der Fehlerursache (hoffentlich) aus dem Rennen ist, absolut sicher bin ich mir auch nicht. Aber vielleicht kann der ein oder andere noch was aus dem Wireshark Protokoll entnehmen.... @Oliver: Aus dem ESP (IDE Monitor Log) habe ich soweit mir möglich war alles Infos entnommen; der Webserver-Handler, der beim Aufruf des Endpunktes aufgerufen wird, wird im Fehlerfalle nicht aufgerufen
:
Bearbeitet durch User
Alexander schrieb: > Konntest Du mit einer eMail was anfangen? (WIFI_NONE_SLEEP, ARP Cache) Danke Alex, habe ich bekommen und bin alle KI Vorschläge durchgegangen: - WIFI_NONE_SLEEP hatte ich schon berücksichtigt, hat aber nichts geändert - ESP Cache hatte ich gemonitored sofern es möglich war, auch hier keine Einschnitte, es war überall noch viel Luft nach oben
Wulf D. schrieb: > Klaus schrieb: >> Oliver S. schrieb: >>> Es hilft Nix, aber da wirst du auf dem ESP mal ergründen müssen, was >>> genau dem fehlt. Vielleicht bringt das dann mehr Erkenntnisse. >> >> Du bist also sicher, dass das Paket beim ESP ankommt? > > Frage ich mich auch schon länger, leider mag Bernd Laura nicht auf dem > ESP nachsehen. Daran hab ich lange rumgedoktert; 100% ausschließen kann ich eine ESP Ursache nicht, aber alle Analysen/Logs/empirische Versuche deuten darauf hin, dass der ESP aus dem Spiel ist....aber wer weiss...(s. oben)
Wulf D. schrieb: > > > Könntest Du bitte in beiden Situationen einen Wireshark-Log anfertigen? > Brauchst den nicht aufbereiten, einfach hier rein posten. > > s.oben Wulf
Eine gebrandete Fritzbox von 1&1?
Bernd Laura schrieb: > s.oben Wulf Der Wireshark-Log sieht tipptopp aus, auch vom Zeitverhalten alles plausibel. Außer dass der ESP den zweiten scheinbar http get einfach ignoriert. Oder der Router schluckt das http get zum ESP: an welcher Stelle klinkt sich Wireshark ein? Läuft das auf dem anfragenden PC? Wenn du low-Level auf dem ESP die Pakete nicht sicher registrieren kannst, könnte man mit einem zweiten Rechner mit Wireshark und einem Hub unmittelbar vor dem ESP schauen, ob der Router die http get frisst. Eine Kleinigkeit fällt in dem Wireshark-Log doch auf: Das beantwortete http get hat eine Länge von 132 Byte, die beiden folgenden, ignorierten 407 Byte. Man könnte im Wireshark die Pakete genauer anschauen. Vielleicht adressieren die nicht vorhandene Resourcen. Aber irgendwas müsste der ESP doch antworten, deshalb glaube ich nicht, dass es hier hakt.
.● Des|ntegrator ●. schrieb: > Eine gebrandete Fritzbox von 1&1? Sie (7530 AX) ist von 1&1 als Provider gestellt, yep Warum, sind die anders als "Originale" von AVM ?
Wulf D. schrieb: > Bernd Laura schrieb: >> s.oben Wulf > > Der Wireshark-Log sieht tipptopp aus, auch vom Zeitverhalten alles > plausibel. Außer dass der ESP den zweiten scheinbar http get einfach > ignoriert. Genau das ist der fragwürdige Knackpunkt - bekommt der ESP den GET überhaupt noch oder bekommt er ihn und ignoriert ihn? Meine ESP Logs sind nur im "sichtbaren" ESP Code möglich und die sagen, es kommt erst gar nichts an. Weiss aber nicht, ob irgendeine Lib, die ich nicht loggen kann, vorher da noch die Finger drin hat. Aber habe die Libs schon ausgetauscht (andere Version, andere Typen async vs. syn), und es haben sich keine Änderungen im Verhalten ergeben. Auch die Tatsache, dass in der stabilen Fehlersituation ein (mehrfacher) Restart des ESP das Problem nicht auflöst - ein einziger Restart des Basis-Routers aber direkt, ist doch ein deutliches Zeichen, dass am ESP erst gar nichts ankommt bzw. der Router die Fehlerquelle zu sein scheint. > Oder der Router schluckt das http get zum ESP: an welcher Stelle klinkt > sich Wireshark ein? > Läuft das auf dem anfragenden PC? Ja, der PC als Client (Browser) - auf dem läuft auch Wireshark (Hatte aber auch Browser auf dem Handy versucht, gleiche Effeket, aber die sind nicht geloggt im obigen Shot) > Wenn du low-Level auf dem ESP die Pakete nicht sicher registrieren > kannst, könnte man mit einem zweiten Rechner mit Wireshark und einem Hub > unmittelbar vor dem ESP schauen, ob der Router die http get frisst. > > Eine Kleinigkeit fällt in dem Wireshark-Log doch auf: > Das beantwortete http get hat eine Länge von 132 Byte, die beiden > folgenden, ignorierten 407 Byte. > Man könnte im Wireshark die Pakete genauer anschauen. Vielleicht > adressieren die nicht vorhandene Resourcen. Aber irgendwas müsste der > ESP doch antworten, deshalb glaube ich nicht, dass es hier hakt.
Vielleicht mal einen ESP32 als WLAN Sniffer einsetzen und dann mit Wireshark auswerten? Dann siehst du ob das Paket zum Webserver gesendet wird. Hier scheint es solch ein Projekt zu geben. Hab es selber nicht getestet, bin nur gerade darüber gestolpert. https://github.com/yannpom/esp32sniffer
Wie wäre es wenn du auch mal den Fritz support anhaust. Die Fritzbox kann doch auch mitloggen: Hilfe&Info- Frtizbox Support Paketmitschnitt Paketmitschnitte sind sehr detaillierte Protokolle, die dem AVM-Support eine tiefgehende Analyse bestimmter Fehlersituationen ermöglichen. Falls sie benötigt werden, wird das AVM-Support Team Sie bitten, Paketmitschnitte zu erstellen und an den Support zu senden. ... Keine ahnung in welchem Format das File logt aber das ist doch mal was für Fritzsupport Und für weitere Versuche empfehle ich den PC per LAN Kabel anschließen.
Chris K. schrieb: > Und für weitere Versuche empfehle ich den PC per LAN Kabel anschließen Geniale Idee, denn Bernd Laura schrieb: > Wenn ein Teilnehmer nicht am WLAN Basisrouter angemeldet ist, > funktioniert es.
Update: Basierend auf Chris Vorschlag den FritzBox Logger zu nutzen, wird es ganz dubios: Client und Webserver direkt am Basisrouter angemeldet, womit sich ja der Fehler reproduzieren lässt. Wenn ich abe rnun stabil im Fehlerfalle bin und das Logging in der FritzBox starte, löst sich der Fehler direkt auf. Anbei ein Kurzvideo, das die Situation zeigt (links der Brwoser mit Endpunkt IP/status, rechts die FritzBox mit Logginghandling) Musste das mp4 File zippen, da es zu gross ist (1,3min Dauer)
Bernd Laura schrieb: > Wenn ich abe rnun stabil > im Fehlerfalle bin und das Logging in der FritzBox starte, löst sich der > Fehler direkt auf. Beim Mitloggen muss die Fritzbox die Interfaces in den Promiscous-Mode schalten. Dass dadurch der Fehler nicht mehr auftritt, weil eben Pakete nicht mehr (fälschlicherweise) gefiltert werden, ist nicht ganz unerwartet. Jedenfalls bin ich mir (wie eigentlich von Anfang an) sicher, dass der Fehler an der Fritzbox liegt und nicht an deinen ESPs.
Klaus schrieb: > Bernd Laura schrieb: >> Wenn ich abe rnun stabil >> im Fehlerfalle bin und das Logging in der FritzBox starte, löst sich der >> Fehler direkt auf. > > Beim Mitloggen muss die Fritzbox die Interfaces in den Promiscous-Mode > schalten. Dass dadurch der Fehler nicht mehr auftritt, weil eben Pakete > nicht mehr (fälschlicherweise) gefiltert werden, ist nicht ganz > unerwartet. > > Jedenfalls bin ich mir (wie eigentlich von Anfang an) sicher, dass der > Fehler an der Fritzbox liegt und nicht an deinen ESPs. Klaus, der Meinung bin ich auch. Vor allem die Tatsache, dass ein Restart der Box den Fehler auch auflöst während ein Neustart des ESP überhaupt keinen Einfluss hat, ist ein Hinweis, dass es eher an der Fritz Box liegt. Auf der anderen Seite frage ich mich, wieso der "Umweg" über den Repeater das Problem vermeidet. Nur dann, wenn beide Teilnehmer (über WLAN) direkt an der 7530 hängen tritt das Problem auf. Eigentlich sollte man meinen, je kürzer der Weg zw. Client und Server, desto unkritischer sollte es sein, aber hier ist es umgekehrt.
:
Bearbeitet durch User
Und damit wäre es nun Zeit, den Support in Anspruch zu nehmen. Das sind jetzt tatsächlich eine ganze Menge an Informationen mit denen die was anfangen können sollten. Wie schon zuvor geschrieben: Meine Erfahrungen mit dem Fritz (damals noch AVM) Support mit solchen Sachen sind durchaus positiv, und bei dem "meine Tasmotas bekommen kein DHCP" habe ich den Fall dann nur deswegen ungelöst gelassen weil ich a) einen funktionierenden Workaround und b) keinen Bock auf "versuche es bitte mal mit Standardeinstellungen" hatte. Wobei ich das durchaus nachvollziehen kann, daß sie mein "Gebastel" erst mal ausschließen wollten. Wäre ich auf der anderen Seite dieses Tickets gewesen, wäre das wahrscheinlich die allererste Antwort gewesen ;-) Also meine Erfahrung aus den letzten 20 Jahren ist: die schauen sich das durchaus an und versuchen zu helfen, manchmal ist das Problem dann auch einfach "still und heimlich" in einem der nächsten Updates gefixt. Gefühlt würde ich sagen, daß da der Support zwar öfters mal das Ticket mit "das ist nicht im Scope" irgendwann zu macht, aber intern das an die Entwickler weitergegben wird und irgendeiner sieht dan "Oh, da ist ja was wirklich kaputt im Code" und ein zukünftiges Update fixt das dann still, ohne viel Federlesens drum zu machen. Wie will man so einen Fix auch dem normalen DAU im Changelog beschreiben?
Stefan S. schrieb: > Und damit wäre es nun Zeit, den Support in Anspruch zu nehmen. Das sind > jetzt tatsächlich eine ganze Menge an Informationen mit denen die was > anfangen können sollten. > Habe ich gemacht, Stefan, Aber ich bin da eher pessimistisch. Einen ESP als Webserver am 7530 (Heimnetz) zu betreiben und daraus resultierende Probleme zu beheben, sieht der AVM Support sicherlich nicht als deren Aufgabe an, obgleich das Problem/Ursache augenscheinlich am 7530 liegt. Mir wäre schon geholfen, wenn sie sagen, ja, Problem bekannt, liegt aus dem und dem Grund am Router, kann aber nicht gelöst werden, bitte Workaround(Repeater oder LAN Verbindung wenn möglich) nutzen. Aber so ist das unbefriedigend, da ich nicht sicher sein kann, ob das Problem nicht doch irgendwann mal auch mit Workaround auftritt. > Wie schon zuvor geschrieben: Meine Erfahrungen mit dem Fritz (damals > noch AVM) Support mit solchen Sachen sind durchaus positiv, und bei dem > "meine Tasmotas bekommen kein DHCP" habe ich den Fall dann nur deswegen > ungelöst gelassen weil ich a) einen funktionierenden Workaround und b) > keinen Bock auf "versuche es bitte mal mit Standardeinstellungen" hatte. > Wobei ich das durchaus nachvollziehen kann, daß sie mein "Gebastel" erst > mal ausschließen wollten. Genau das ist auch meine Befürchtung, die machen da, weil es doch nicht in ihren Standard passt, nichts. Hatte schon einige Standardprobleme bei AVM gemeldet, aber außer alten Support-Links, die ich selber schon zig Mal gelesen hatte, kam dann leider nichts Hilfreiches von denen. > Wäre ich auf der anderen Seite dieses Tickets gewesen, wäre das > wahrscheinlich die allererste Antwort gewesen ;-) > > Also meine Erfahrung aus den letzten 20 Jahren ist: die schauen sich das > durchaus an und versuchen zu helfen, manchmal ist das Problem dann auch > einfach "still und heimlich" in einem der nächsten Updates gefixt. > Gefühlt würde ich sagen, daß da der Support zwar öfters mal das Ticket > mit "das ist nicht im Scope" irgendwann zu macht, aber intern das an die > Entwickler weitergegben wird und irgendeiner sieht dan "Oh, da ist ja > was wirklich kaputt im Code" und ein zukünftiges Update fixt das dann > still, ohne viel Federlesens drum zu machen. Wie will man so einen Fix > auch dem normalen DAU im Changelog beschreiben?
Ich wäre da trotzdem erst mal optimistisch. Dein Anwendungsfall "ESP im WLAN auf den per http zugegriffen werden soll" ist heutzutage ein Standardanwendungsfall. Jede Tasmota oder Tuya Steckdose, "smart" WLAN gesteuerte Lampen etc. sind genau sowas. Das werden sie nicht einfach als "uns doch egal" ablehnen, sollten sie zumindest nicht. Falls das Ticket sich in diese Richtung entwickelt, kannst du ja erwähnen daß dieselbe Hardware in vielen kommerziell verfügbaren "Appliances" auch verwendet wird, für den Fall daß der Supporter da nicht von selber drauf kommt. Du hast sogar einen Hinweis mitgeschickt "wenn ich den Monitor Mode an mache funktioniert es plötzlich" und -- anders als ich ;-) -- kein spezial-gebastel im Netzwerk mit eigenem DNS / DHCP Server. Ich drücke dir (und indirekt auch mir) die Daumen.
Bernd Laura schrieb: > Aber ich bin da eher pessimistisch. Einen ESP > als Webserver am 7530 (Heimnetz) zu betreiben und daraus resultierende > Probleme zu beheben, sieht der AVM Support sicherlich nicht als deren > Aufgabe an, obgleich das Problem/Ursache augenscheinlich am 7530 liegt. Du könntest, falls Du ein ungenutztes Notebook herumliegen hast, ja auf diesem mal ein Betriebssystem Deiner Wahl installieren, das via WLAN mit der Fritzbox verbinden (darauf achten, daß Du nur ipv4 verwendest; Deine ESP32 werden kein ipv6 sprechen, oder?) und auf dem Betriebssystem einen Webserver wie z.B. Apache installieren - in der Standardkonfiguration, ohne https, nur auf Port 80 lauschend. Wenn das Betriebssystem selbst nicht allzuviel Eigenleben im WLAN anstellt, könnte ja möglicherweise das Filterproblem auch damit auftreten. Wegen des Eigenlebens ist Windows als Betriebssystem eher ungünstig, irgendein minimalistisches Linux sollte da besser kontrollierbar sein; allerdings muss das mit der WLAN-Hardware des Notebooks zurechtkommen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.