Im Oktober/November letzten Jahres habe ich mir auf Basis des ESP8266 in Kombination mit einenm BH1750 einen Helligkeitssensor gebaut, der die Beleuchtung rund ums Haus steuert. Das funktioniert soweit auch tadellos. Das WLAN-Netz, in das der ESP8266 funkt, ist rein intern. Externe Verbindungen hat und braucht die ganze Anlage nicht. Nun habe ich einen neuen Router bekommen und mich darüber gewundert, dass der ESP8266 im Minutenrythmus eine Verbindung zur IP-Adresse 128.85.255.63 aufbaut (es versucht) und systematisch Ports im oberen Bereich scannt. Der abgescannte Bereich liegt so zwischen Port 30.000 und 62.000. Vor zwei Wochen noch hat der ESP8266 eine andere IP-Adresse angepollt (112.82.255.65). Verbindungen nach Außen ins Internet waren bis zur Entdeckung dieses Verhaltens nicht möglich. Ich kann ausschließen, dass der ESP8266 auf eine Anfrage aus dem Internet reagiert. Inzwischen habe ich dem ESP8266 Zugriff nach außen gewährt, meinen Traffic-Scanner eingeschaltet und plotte die Pakete nun mit. 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. Hierfür habe ich als Grundlage den Webserver aus dem Arduino-IDE (1.6.4) „ESP8266AdvancedWebserver“ verwendet. Die ESP8266 Libraries habe ich über den Board-Manager des Arduino IDEs installiert. Meinen eigenen Code und die als Quelltext vorliegenden LIBs habe ich durchgesucht und konnte keine Routine finden, die das Verhalten erklären könnte. Es steht also zu vermuten, dass Espressif in seinen LIBs eine solche „Nach-Hause-Telefonier-Funktion“ implementiert hat. 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> Da ich die Situation nicht noch einmal nachstellen kann, wollte ich hier im Forum fragen, ob ihr alle mal auf Eure Router schaut. Vielleicht telefoniert Euer ESP8266 ja auch nach Hause. Ich habe mal einen Screenshot vom Routing-Table angehängt und eine PCAP-Datei, die Ihr Euch mit Wireshark anschauen könnt. Die 192.168.1.71 ist der Helligkeitssensor. Es würde mich freuen, wenn Ihr hier Positiv-/Negativ-Berichte postet. Viele Grüße Jo
Angehängte Dateien:
-
Lichtsensor_Bild_klein.png
350 KB -
Lichtsensor_Router1.png
9 KB -
Lichtsensor_Router2.png
14 KB
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.
Angehängte Dateien:
-
Portland.jpg
99 KB -
Shanghai.jpg
110 KB
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.
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.
Wenn die IP-Adresse gewechselt hat, liegt es vielleicht daran, dass per DNS angefragt wird. Installiere mal einen Wireshark und poste das Ergebnis.
wie oft treten diese 'Kommunikationsversuche' denn auf? Damit man vorbereitet ist ob man 10min oder 2Wochen tracen muss.
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 kann mich dunkel an einen Artikel erinnern bei dem die Chinesen sogar in den Bügeleisen WIFI-Module installiert haben und die buchen sich in alle offenen WLAN-Netze ein und fungieren als Bot... Ich finde nur den Link nicht mehr! Nachtrag/Vorschlag: 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
:
Bearbeitet durch User
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.
@ 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
Angehängte Dateien:
-
Lichtsensor_Router3.png
2,5 KB
@ 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.
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.
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.
Ich habe gerade dein .pcap entdeckt(hatte ich vorher nicht gesehen) In deinem Netzwerk ist was faul. Die ganzen Fehler die Wireshark anzeigt sind nicht normal. Ich habe auf dem Gebiet auch nur begrenzt Ahnung aber normal ist das nicht. Vielleicht zerwürfelt ja dein Tracegerät schon die Logdatei.
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...
Ich hab mir die ESP8266.pcap auch mal angeschaut. 129.0.0.10 Schick die gleiche HTTP Anfrage wie die 1.254 und 2.149 an 1.71 Das geht nicht da - Der Verbindungsaufbau von 129.0.0.10 fehlt - Dein NAT im Router das unterbunden hätte - Das ganz innerhalb von ms passiert (129.0.0.0/17 sitzt in Cameroon) 129.0.0.20 Schick die gleiche HTTP Antwort wie die 1.71 an 1.254 und 2.149 Das geht nicht da - Der Verbindungsaufbau von 129.0.0.20 fehlt - Dein NAT im Router das unterbunden hätte - Das ganz innerhalb von ms passiert (129.0.0.0/17 sitzt in Cameroon) Wenn die 2.149 dein PC ist, was ist dann die 1.254? Die schick die gleiche Anfrage immer Syncron zum PC. Entweder dein Router Zeichnet das Paket 2x auf (dann ist die Absender Addr Falsch oder er macht NAT ohne den Absender Port zu ändern, beides unwahrscheinlich) oder das Paket wird vom ESP Gespiegelt. Das würde auch den restlichen müll erkären. Der ESP Sendet jedes Paket 3x: 1. Richtig 2. Flasche Absender Addr 3. Komplett vermurkst (129.0.0.0/17) & Co. Sieht für mich aus als wenn da viele Flöhe im TCP/IP Stack sind. Und definitiv nicht nach "nach-Hause-Telefonieren" aus. Poste doch mal einen Aufbau von deinem Netzwerk mit IP-Adressen und einen längeren .pcap per Monitor Port. Dein Router Filtert nämlich ein reihe Wichtiger Informationen (MAC) aus.
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
> 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 :) Könnte auch ein nicht dereferenzierter Pointer sein (0x3FFFxxxx ist der RAM-Bereich im 8266). Die Angabe der Header-Dateien helfen da nicht weiter, da das Problem in deinem nicht geposteten Code liegt könnte.
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
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.
Fl schrieb: > 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. Soweit ich weiß bezieht sich diese Auto-Update Funktion nur auf die originale AT-Firmware. Die Arduino Firmware hat sowas meines Wissen nach nicht, weswegen ich mich meinen Vorpostern anschließe und einfach denke dass irgendwo ein Fehler im Code ist, wodurch diese Pakete auftreten...
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
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.