ESP8266 "telefoniert nach Hause"

das sieht merkwürdig aus.

Wenn die SRC und DEST getauscht wären, würde das alles einen Sinn 
ergeben. Denn der Absender Port zählt automatisch hoch. Und als Ziel 
macht auch der Port 80 sinn. Absender Port 80 ist merkwürdig, dann das 
sollte ja schon der Webserver sein LISTEN drauf haben, außerdem darf nur 
ROOT ports < 1024 öffnen.

Also die Lookups auf die IPs machen kein Sinn. Ich denke nicht das er 
irgendwie nach Hause telefoniert. Ich denke eher vielmehr das das ein 
Fehler der Software ist.

Als vermutung würde ich mal drauf tippen das es vielleicht der OTA 
Bootloder ist, vielleicht ist da was voreingestellt, ansonsten werde ich 
bei mir mal schauen.

Das sieht eher danach aus, dass eine Funktion aktiviert wird, die 
versucht einen Wetterdatensatz anzufordern. Du solltest versuchen in den 
Quelltexten nach den IP-Adressen zu forschen.

@opidus:

Ich denke, Du hast den Artikel nicht richtig gelesen und/oder 
verstanden. Ein Linux-System (mit einer internen, privaten IP) fordert 
Daten an.

In diesem Fall handelt der ESP8266 von sich aus und pollt eine externe 
IP. Das habe ich aber nicht programmiert.

>Du solltest versuchen in den Quelltexten nach den IP-Adressen zu forschen.

Danke für den Tipp. Bevor ich das hier gepostet habe, habe ich schon 3 
Wochen Investigation hinter mir. Die Adressen konnte ich in den als 
Source-Code vorhandenen Bibliotheken nicht finden. Das steht übrigens 
auch schon oben im initialen Post.

Greetz
Jo

Peter II schrieb:

> Absender Port 80 ist merkwürdig

Merkwürdig ist das natürlich, aber keinesfalls unmöglich.

> dann das
> sollte ja schon der Webserver sein LISTEN drauf haben

Es ist natürlich trotzdem recht problemlos möglich, Pakete zu versenden 
mit Port 80 als Absender. Mir fallen da auf Anhieb mindestens drei 
verschiedene Methoden zu ein.

> außerdem darf nur
> ROOT ports < 1024 öffnen.

Immer diese unzulässigen Verallgemeinerungen. Merke: Es gibt OS', da 
gibt es gar keine differenzierten Benutzerrechte. Mehr noch: ES gibt 
OS', da gibt es nichtmal das Konzept eines "Benutzers". Und nicht 
zuletzt: es gibt OS', die eigentlich nichtmal wirklich OS sind, gerade 
im Bereich der µC...

Soviel zu deiner Analyse...


Allerdings, eine bessere Analyse kann ich auch erstmal nicht anbieten.

Das pcap-File ist nämlich sehr wahrscheinlich viel zu stark gefiltert, 
um wirklich sagen zu können, wer hier den aktiven Part spielt, ob also 
der ESP tatsächlich "nach Hause telefoniert". Der OP sollte mal ein 
ungefiltertes Capture des fraglichen Zeitraumes posten, dann könnte man 
sehr wahrscheinlich schon viel mehr sehen.

Kurzfassung: Ich glaube eher nicht an die Heimtelefonier-Theorie des OP, 
halte sie allerdings auch nicht für völlig ausgeschlossen.

Jo schrieb:
> @opidus:
>
> Ich denke, Du hast den Artikel nicht richtig gelesen und/oder
> verstanden. Ein Linux-System (mit einer internen, privaten IP) fordert
> Daten an.

Das ist auch unwidersprochen. Trotzdem wird im ESP eine Routine 
aktiviert, die einen externen Server kontaktiert.

> In diesem Fall handelt der ESP8266 von sich aus und pollt eine externe
> IP. Das habe ich aber nicht programmiert.
>
>>Du solltest versuchen in den Quelltexten nach den IP-Adressen zu forschen.
>
> Danke für den Tipp. Bevor ich das hier gepostet habe, habe ich schon 3
> Wochen Investigation hinter mir. Die Adressen konnte ich in den als
> Source-Code vorhandenen Bibliotheken nicht finden. Das steht übrigens
> auch schon oben im initialen Post.

Das steht aber nicht ausdrücklich, dass du nach den Adressen gesucht 
hast.

Klinke mich jetzt aus, da ich so oder so nicht helfen kann.

c-hater schrieb:
> Soviel zu deiner Analyse...

ja, aber alles in allen - warum sollte man es so machen um Daten zu 
übertragen? Warum sollte man irgendwelche Ports testen müssen? Wenn man 
Daten zu seinen eigenem Server überträgt, wird man in den meisten Fällen 
den Port wissen und Maximalen zur Redundanz verschieden IPs versuchen.

Zeige uns doch mal das SYN packet, dann sieht man in welcher Richtung 
die Verbindung aufgebaut wird.

Vielleicht hilft das weiter.

http://www.utrace.de/?query="IP-Adresse";

Und vielleicht hat sich der ESP8266 nur im WLAN vertan und wollte über 
den Nachbarn raus. :-) :-) :-) :-) :-) :-) :-)

@Peter II

>ja, aber alles in allen - warum sollte man es so machen um Daten zu
>übertragen? Warum sollte man irgendwelche Ports testen müssen?

Das habe ich mich auch gefragt. Das ganze ist sehr nebulös. Da ich den 
Source-Code habe, nichts dergleichen programmiert habe und das Teil bis 
vor kurzem nicht mal Internet-Zugang hatte, ist das sehr merkwürdig.

Bevor ich Erklärungen finden möchte, wäre es interessant zu sehen, ob 
ich der Einzige bin, bei dem das Phänomen auftritt. Da lohnt es nicht 
wirklich, der Sache nachzugehen.

Deshalb nochmal mein Appell an alle ESP8266-Besitzer. Wenn Ihr auch 
einen Web-Server laufen habt, vielleicht sogar obige Libraries verwendet 
und wisst, wo bei Eurem Router die Routing-Tabelle ist, schaut doch mal 
nach ob Ihr bei Euch auch merkwürdige Einträge findet und postet es 
hier.

112.82.255.65 ist in Shanghai

Peter II schrieb:

> ja, aber alles in allen - warum sollte man es so machen um Daten zu
> übertragen?

Um eben diese Datenübertragung im allgemeinen Traffic möglichst gut zu 
verstecken, was denn sonst? Wenn's jedem auch nur halbgebildeten 
Frickler sofort auffallen würde, hätte es nicht lange Bestand, und würde 
nicht nur den Mechanismus "verbrennen", sondern obendrein auch noch die 
Quelle des Codes kompromittieren. Aber wer weiss, vielleicht ist gerade 
letzteres ja sogar das Ziel des hypothetischen Angreifers...

Ein "Spiel" (im theoretischen Sinn des Begriffs) ist unendlich komplex 
und man muss darin auch mit solchen Zügen rechnen, wie der "false 
flag"-Attacke. Dass also jemand einen eigentlich vertrauenswürdigen 
Partner als Feind diskreditiert, indem er ihm Aktionen unterschiebt, die 
er nie ausgeführt oder zumindest nie beabsichtigt hat.

> Warum sollte man irgendwelche Ports testen müssen?

Wo siehst du einen Port-Test? Ich sehe in allen Fällen Daten über eine 
offensichtlich etablierte TCP-Verbindung laufen. Nix Test. Alle diese 
Daten müssen eine Vorgeschichte haben. Und Auskunft dazu kann halt nur 
ein ungefiltertes Log geben. Genau deswegen habe ich das auch 
reklamiert.

> Zeige uns doch mal das SYN packet, dann sieht man in welcher Richtung
> die Verbindung aufgebaut wird.

Genau. Das ist einer der Punkte. Aber immer noch nicht ultimativ. Auch 
SYN-Pakete lassen sich schließlich recht problemlos fälschen. Zumal hier 
NAT (masquerading) von vornherein ganz legal im Spiel sein muss...

Ich hatte auf meinem Modul auch mal den Google-Bot und auch den von 
Baidu. :) Muss nicht immer böswillig sein.

Marc H. schrieb:
> Leite den Traffic mal um und lass ihn an einen PC weiterleiten.
> Akzeptiere den Connectionversuch und schau was über die Leitung läuft
> mit WireShark

Ich habe das etwas anders gelöst. Der Router hat einen Paket Sniffer, 
der die Pakete an einen Server weitergeleitet werden und dort wird dann 
alles protokolliert. Der Intercept findet bei mir bereits auf dem Router 
statt. Ich filtere derzeit alles heraus, was als Absende-/Zustelladresse 
die 191.168.1.71 hat (also die IP die der Lichtsensor hat). Der 
Connectionversuch würde akzeptiert. Der ESP8266 scannt aber wie bekloppt 
alle Ports der IP-Adresse durch, ohne das zu einem Connect kommt. Das 
ist das Problem. Sonst könnte ich den Handshake und die Payload hier 
posten. Hab' ich aber nicht.

Deswegen interessiert es mich, ob auch ESP8266 anderer Nutzer dasselbe 
Verhalten zeigen. Dann könnte man vielleicht mal gemeinsam der Sache auf 
den Grund gehen.

----

@c-hater

An einem ungefilterten Log arbeite ich. Derzeit logge ich alles, was als 
Absende-/Zustelladresse die 191.168.1.71 hat. Das poste ich dann 
vermutlich morgen Vormittag.

Jo, hier hat einer schon Freitag :-)

@ snowfly

Bei mir tritt der Versuch ca. 1x pro Minute auf. Manchmal dauert es auch 
bis zu 90 sek., jeweils 2 Ports zur gleichen Zeit.

Jo schrieb:
> Bei mir tritt der Versuch ca. 1x pro Minute auf. Manchmal dauert es auch
> bis zu 90 sek., jeweils 2 Ports zur gleichen Zeit.

Dann hast Du die falschen Protokolle gepostet ...

Troll woanders

Warum tragen die Pakete in dem pcap File eigentlich sowohl in der Quell- 
als auch in der Ziel-MAC den Wert 00:00:00:00:00:00?

Wenn hier jemand mit dem Internet kommunizieren möchte, sollte hier 
wenigstens die MAC des nächsten Router stehen.

Thomas schrieb:
> Warum tragen die Pakete in dem pcap File eigentlich sowohl in der Quell-
> als auch in der Ziel-MAC den Wert 00:00:00:00:00:00?

Na ich vermute mal ganz dreist, weil das alles hier nur ein FAKE ist ...

Dieter F. schrieb:
> Na ich vermute mal ganz dreist, weil das alles hier nur ein FAKE ist ...

Diese Vermutung liegt recht nahe. Oder es ist ein Dekodierfehler im 
Wireshark bzw. wurden die Pakete falsch mitgeschnitten

Thomas schrieb:
> Diese Vermutung liegt recht nahe.

Bingo!

@ Jim Dieter Quakenbusch

>Dann hast Du die falschen Protokolle gepostet ...
>Troll woanders

Muss ich das verstehen? Was ist daran falsch? Hab' ich da etwas 
übersehen, außer einem "ist schon Freitag", "das ist ein Fake" und 
"Troll woanders". Dann bitte ich Entschuldigung.

Ich meine es recht ernst mit diesem Thema. Es ist nicht witzig, wenn 
Dein Rechner (auch wenn es nur ein µC ist), Sachen macht, die er nicht 
machen sollte. Er vielleicht Daten verschickt (WLAN-Zugangsdaten??) die 
wohl besser geheim bleiben.

Wenn Du Dir obige Grafik anschaust ("Lichtsensor_Router2.png") so siehst 
Du dort die Timeout-Zeit der Verbindungen, die offensichtlich anfangs 
24h beträgt (warum ist mir übrigens NICHT klar). Wenn Du jetzt mal durch 
die Spalte guckst wirst Du feststellen, dass der Time-Out bei einigen 
Ports eine Reihe bildet: 19:01:19 - 19:02:19 -19:03:19 - 19:04:18.

Mit anderen Worten: der ESP8266 öffnet ungefähr jede Minute einen Port 
bei der Zieladresse. Was man -zugegeben- nicht sieht: in einem anderen 
Portbereich wird fast zeitgleich parallel ein weiterer Port geöffnet. 
Ich habe nochmal eine Grafik angehängt, wo zeitgleich wohl 3 gleich 
Ports geöffnet wurden.

Das mit dem Dekodierfehler halte ich für Quatsch, da dann die 
Routingtabelle des Routers (auch) ein Problem haben müsste. Der 
funktionier aber einwandfrei.

Kannst Du also bitte Deinen "Troll-Vorwurf" etwas konkretisieren. Wenn 
Du Wissen über derartige Themen hast, teile es uns doch bitte mit, 
Dieter.

Wenn Du möchtest lade ich Dich auch gerne ein und Du kannst Dir die 
Sache hier persönlich ansehen.

Jo schrieb:
> Wenn Du Dir obige Grafik anschaust ("Lichtsensor_Router2.png")

Veralbere doch bitte jemand anders - die ursprünglich "veröffentlichen" 
Router1.png und Router2.png sehen anders aus.

Die jetzt - NEU - hinzugefakte Router3.png weist kleinere Abstände aus - 
Word oder Notepad oder ... sei Dank.

TROLL - und das war es jetzt für mich - veralbere wer sich veralbern 
lassen mag :-)

Jo, bist du bereit dein Modul zu verschicken? Wie kann man dich 
kontaktieren?

Jo schrieb:
> Folgende Libraries verwende ich in meinem Code:
>
> #include <ESP8266WiFi.h>
> #include <WiFiClient.h>
> #include <ESP8266WebServer.h>
> #include <ESP8266mDNS.h>
> #include <Wire.h>
> #include <math.h>

Wenn Du diese rein zufällig selbst compiliert haben solltest aus den 
Quellen, kannst Du ja selbst mal nachsehen? Irgendwo sollte ja eine IP 
zu finden sein? grep?

oszi40 schrieb:
> Wenn Du diese rein zufällig selbst compiliert haben solltest aus den
> Quellen, kannst Du ja selbst mal nachsehen? Irgendwo sollte ja eine IP
> zu finden sein? grep?

DNS wurde aber auch schon erfunden.

Thomas schrieb:
> Quell- als auch in der Ziel-MAC den Wert 00:00:00:00:00:00?

Ziel-IPs:
70 52 FF 3F
80 55 FF 3F

Solche Zufälle Gibbs eigentlich auch nicht. Da ist entweder was kaputt, 
oder schlecht gefaked :)

Ok. Nochmal.

Die Tabelle "Lichtsensor_Router3.png" ist anders sortiert. Nach 
Time-Out.

Ich Vollpfosten meine die Sache ernst. Vielleicht habe ich nicht soviel 
Ahnung wie Ihr, aber deshalb poste ich hier ja.

Ich hatte gedacht, so ein Forum wie das Diese hier wäre dazu da, Hilfe 
zu bekommen und nicht beschimpft zu werden. Im OP hatte ich gefragt, ob 
es andere Nutzer eines ESP8266 gibt, die ein ähnliches Phänomen haben. 
An eine Analyse habe ich mich noch überhaupt nicht rangetraut.

Danke Jim Dieter. :-) Du bekommst den Orden für die größte Produktivität 
hier.

@ Thomas: das mit den fehlenden Mac-Adressen war mir auch schon 
aufgefallen.
Ich konnte es aber nicht interpretieren, da ich solche Traces 
normalerweise nicht lese. Ich kann es im Moment nicht ändern.

@c-hater
Aus dem ESP8266 kann ich direkt keinen Trace ziehen. Da ist erst der AP, 
dann der Switch und erst am Router kann ich etwas rausziehen. Das sah 
dann so aus, wie das, was ich hier gepostet habe.

Ich habe jetzt ein paar Einstellungen geändert und erhalte das hier 
(siehe Anlage). Das ist mehr als vorher.

Ich habe auch eine weitere Erkenntnis: da ich den Traffic vom Sensor 
nicht draufhaben wollte, habe ich den Cron-Job der diesen triggert 
auskommentiert. Dann gabs auch kein "nach Hause telefonieren" mehr. Ich 
habe jetzt zwei Requests von meienm PC aus gemacht und diese am Router 
gesniffert. (siehe Anlage)

Und ja, ich habe das Modul "selbst" im Arduino IDE compiliert. Ich habe 
die Quelldateien alle durchgeschaut, aber nichts auffälliges gefunden. 
Es werden aber noch am Ende noch einige Libs von Espressif (?) 
dazugelinkt. Da vermute ich die dubiose Routine drin, vielleicht auch 
nur ein Bug. Ich bin allerdings nicht in der Lage da ein 
Reverse-Engineering durchzuführen.

Jo schrieb:
> Ich habe auch eine weitere Erkenntnis: da ich den Traffic vom Sensor
> nicht draufhaben wollte, habe ich den Cron-Job der diesen triggert
> auskommentiert. Dann gabs auch kein "nach Hause telefonieren" mehr.

na ist das nicht die Lösung? Du hast kein "nach Hause telefonieren" 
gefunden sondern dein eigenen Trafik nur falsch interpretiert?

Du schrieb:
> Jo, bist du bereit dein Modul zu verschicken? Wie kann man dich
> kontaktieren?

Schick' einfach eine Mail an johbru1977{at}eclipso.ch. Wir können auch 
skypen.

Chr. M. schrieb:
> Ich habe meinen esp8266 gerade mal über 7 min. getraced
>
> --> keine Verbindung die nicht programmiert ist.
>
> getraced mit FritzBox
> geöffnet in Wireshark
> programmiert mit Arduino 1.6.5
>
> Zeit um mal den Trace rauszurücken.

Ja bei mir das selbe nix was nicht sein soll, allerdings ist auf dem 
getesteten Modulen ESPBasic drauf nutzt die gleichen libs, hab es bei 
allen Modulen getestet die hier in Betrieb sind nix was sich nicht 
erklären läst, die könnten auch wenn sie wollten nicht ins Internet.

@ Peter II

Aber woher kommt die öffentliche IP? Die ist bei mir definitiv nirgends 
drin.(und der Code hat nur 134 Zeilen (inkl. Kommentare))

Vielleicht schaut sich c-hater den Trace ja noch mal an.

Was mich wundert ist, dass es vor dem Paket an die externe Adresse kein 
SYN gibt, sondern nur ein ACK. Vielleicht ein Bug irgendwo.


@snowfly

Danke.

Jo schrieb:
> Aber woher kommt die öffentliche IP? Die ist bei mir definitiv nirgends
> drin.(und der Code hat nur 134 Zeilen (inkl. Kommentare))

da den Router auch den MAC entfernt kann man nicht sagen was er noch dem 
Paket manipuliert.

Ja, eindeutig telefoniert der ESP8266 nach Hause. Scheit mir völlig 
klar.

Das ist auch der Grund dafür, warum ich nie so ein Scheiß (mit 
geschlossenem TCP/IP stack usw.) für meine Projekte nehmen würde.

Danke an Alle für heute.

Ich werde morgen den AP mit dem ESP8266 mal isolieren, das Port 
Mirroring am Switch aktivieren, mein Notebook anklemmen und mit 
Wireshark sniffern. Das hab' ich noch nie gemacht.

Das Resultat poste ich hier dann auch.

Nochmal. Ich hab' das hier nicht gefaked sondern mir war/ist angst und 
bange, dass der kleine Chinese Daten nach Hause funkt. Da es anderen 
Anwendern nicht so geht, bin ich nun etwas beruhigter.

Was den Router angeht: es ist halt das, was er anzeigt. Ich habe bisher 
keinen Grund den Daten zu misstrauen. Sonst hätte ich das hier nicht 
gepostet.

In den Ziel IPs ist ff 3f drin, das ist eine dez 1000. Wenn du in deinem 
Programm die Zieladresse als Variable angelegt hast könnte die durch 
einen Programmfehler überschrieben worden sein. Gibt es irgendwo ein 
Array wo ein Wert = 1000 gesetzt wird?

Petr schrieb:
> Das ist auch der Grund dafür, warum ich nie so ein Scheiß (mit
> geschlossenem TCP/IP stack usw.) für meine Projekte nehmen würde.

ich dachte der Quellcode ist opensource?

JojoS schrieb:
> In den Ziel IPs ist ff 3f drin, das ist eine dez 1000.

Aaaaargh, 16383 natürlich. Ist ja schon spät.  Das hier noch keiner 
geschrien hat...

Jo,

in Deinem letzten pcap (22:50Uhr) fällt mir auf, dass immer wenn so ein 
"nach-hause-telefonier-Paket" kommt, unittelbar davor ein kaputtes Paket 
ist.

In diesem pcap sind das die Pakete mit den Nummern:

27/28
49/50

Ich vermute, beide Pakete sind (z.B. in Folge von Kollisionen) zerstört 
und Wireshark dekodiert diese Fragmente nun als einzelne Pakete. Der 
Inhalt ist damit natürlich sinnfrei.

Es sind auch noch mehr Pakete defekt, was den Verdacht der Kollisionen 
m.E. bestärkt.

Weiterhin gibt es einige Connection-Resets (RST-Bit gesetzt) in dem 
Trace. Dies sind Sessions, die z.B. infolge zu vieler Kollisionen 
abbrechen und neu aufgebaut werden müssen.

Die IP-Adressen 129.0.0.x sind auch fragwürdig,können jedoch auch aus 
den Kollisionsfragmenten entstehen.

Wenn meine Vermutung zutrifft, solltest Du Deine Netzwerkverkabelung 
prüfen und jede Verbindung auf dem Weg der Datenpakete auf möglichen 
Duplex-Mismatch überprüfen. Denn dann hast Du ein Problem in Deinem 
Netzwerk.

Thomas schrieb:
> Ich vermute, beide Pakete sind (z.B. in Folge von Kollisionen) zerstört
> und Wireshark dekodiert diese Fragmente nun als einzelne Pakete. Der
> Inhalt ist damit natürlich sinnfrei.

Gleich nochwas dazu:

Im Paket 52 (SRC 129.0.0.10, DST 192.168.1.254) findet man in der 
Hex-Darstellung die Hex-Zeichen c0 a8 01 fe (= IP 192.168.1.254) und c0 
a8 01 47 (= IP 192.168.1.71) . Allerdings an den falschen Stellen.

Ich denke, dieses "Paket" entstand aus dem Rest eines 
Kollisionsfragmentes und dem Anfang eines regulären Paketes von 
192.168.1.254 an 192.168.1.71. In dieser Kombination würde die Anordnung 
der Bytes auch Sinn machen.

Jo schrieb:
> Danke Jim Dieter. :-) Du bekommst den Orden für die größte Produktivität
> hier.

Herzlichen Dank :-)

https://www.youtube.com/watch?v=U-2DFOyUDAc

Hast Du mehrere Module? Tritt der Effekt bei allen auf?

Es könnte auch sein, dass dein Programmcode irgendwo fehlerhaft ist und 
das RAM falsch beschreibt oder einen Speicherüberlauf auslöst.

Da der IP Stack IMHO nicht in einem separaten geschützten Bereich läuft 
(wie man es vom PC längst gewohnt ist) können Fehlfunktionen deines 
Programms somit Folgefehler im IP Stack auslösen.

Ich habe (etwas später als angekündigt) nochmal einen Trace über den 
Switch gezogen. Da sind jetzt auch die MAC-Adressen drin. Geändert hat 
sich nichts.

Ich habe mich zwischenzeitlich nochmal mit dem Hinweis von Peter II 
beschäftigt. Was auffällt ist, dass der ESP8266 an die 128.85.255.63 
überhaupt keine SYN-Pakete schickt und auch kein SYN-ACK zurückerhält. 
Die 192.168.1.71 schickt nur das ACK-Paket.

@Marcus: ich habe nur ein Modul produktiv. Allerdings werde ich jetzt 
noch einen ESP8266 nachordern und den Quelltext mit Arduino 1.6.7 
nochmal kompilieren. Die 1.6.4 habe ich ohnehin nicht mehr installiert. 
Dem Hinweis von stefanus werde ich mal nachgehen. Vielleicht ist das 
Paket tatsächlich sowas wie ein Speicherüberlauf.

Jo schrieb:
> Ich habe (etwas später als angekündigt) nochmal einen Trace über den
> Switch gezogen.

der sieht auch merkwürdig aus. Die Pakete an 128.85.255.63 sind defekt. 
Uns sie kommen mit dem gleichen Port von dem Paket davor.

Das ist keine sinnvolle Übertragung, entweder ist das Modul defekt oder 
dein Netzwerk läuft nicht stabil.

Peter II schrieb:
> der sieht auch merkwürdig aus. Die Pakete an 128.85.255.63 sind defekt.

Meine Rede.
Wir jagen einem Phantom hinterher, welches es gar nicht gibt.

Ok. Danke an Alle. Ich schlage vor, wir beenden diesen Thread hier 
vorerst.

Ich habe den ESP8266 nochmal bestellt. Lieferung dauert ein paar Tage. 
Einen BH1750 habe ich noch hier. Ich werde das ganze nochmal auf dem 
Breadboard aufbauen und sehen was das nächste Modul mit meinem Code 
unter Arduino 1.6.7 macht.

Das Ergebnis werde ich hier dann posten.

Vor Allem solltest du mal mit einem bewährten Programm testen, statt mit 
deinem eigenen.

Oder du reduzierst dein programm auf eine sehr simple Hello-World 
Variante, wo Speicherüberläufe und falsch genutzte Pointer ganz sicher 
ausgeschlossen sind.

Bevor man die Schuld in fremden Code vermutet, sollte amn immer erst den 
eigenen Code untersuchen. Denn dort steckt der Fehler (egal welcher) 
fast immer.

Jo schrieb:
> Ok. Danke an Alle. Ich schlage vor, wir beenden diesen Thread hier
> vorerst.

Nicht beenden! Nur ruhen lassen. Ich möchte doch noch gerne wissen, was 
die Ursache für dieses Phänomen ist.

Marcus

> Ich möchte doch noch gerne wissen, was
> die Ursache für dieses Phänomen ist.

Ich auch.

Ich habe mal meine Glaskugel angeworfen. Das Ergebniss ist mit etwas 
Vorsicht zu genießen, das Problem ist weit von hier entfernt und 
Kugellinsen fokussieren schlecht auf große Entfernung;)

Jo schrieb:
> Der ESP8266 fungiert als Web-Server auf Port 80 und wird von einem
> kleinen Linux-Rechner regelmäßig gepollt. Dann gibt er den
> Helligkeitswert als Text aus

Jo schrieb:
> Ich habe auch eine weitere Erkenntnis: da ich den Traffic vom Sensor
> nicht draufhaben wollte, habe ich den Cron-Job der diesen triggert
> auskommentiert. Dann gabs auch kein "nach Hause telefonieren" mehr.

Peter II schrieb:
> der sieht auch merkwürdig aus. Die Pakete an 128.85.255.63 sind defekt.
> Uns sie kommen mit dem gleichen Port von dem Paket davor.

Meine Glaskugel sagt also: das Programm auf dem ESP hat einen Bug, 
möglicherweise ein Memmory-Leak oder einen anderen 
Speicherüberschreiber. Der Web-Server antwortet zwar richtig, stürzt 
dann aber ab. Dabei sondert er noch ein (oder einige) defekte Pakete ab. 
Der eingebaute Watchdog bringt ihn dann wieder zum Laufen. Da sich der 
ESP eine Menge über das Wlan im Flash merkt, ist er schnell wieder 
online. Verifizieren könnte man das, wenn man ein Terminal an die 
serielle hängt. Das könnte auch grundsätzlich beim Debuggen helfen.

Take it with a grain of Salt

MfG Klaus

Was ist denn nun aus dem Thema geworden? Heiße Luft?

Hallo,

ich habe mal gelesen, dass man auf dem ESP8266 eine Funktion aktivieren 
kann, damit er automatisch auf dem Herstellerserver nach der aktuellen 
Firmware Sicht und diese ggf. auch installiert. Das würde zumindest die 
IP aus China erklären, da das Modul in China entwickelt wird.

AT+CIUPDATE

Soweit ich mich noch erinnern kann, gibt es diese Auto-Update Funktion 
auch bei der Arduino Firmware.

Nicht in dieser Form...

Aber in anderen Varianten:
https://github.com/esp8266/Arduino/blob/master/doc/ota_updates/ota_updates.md