Hi, Ich habe einen ESP8266 dort spiele ich gerade etwas mit UDP rum. Wenn der ESP und der UDP Sender nicht im gleichen Netzwerk sind erhält er die Nachricht nicht. Muss denn der Sender oder Empfänger im gleichen Netzwerk sein oder mache ich was falsch? Mfg
Franco O. schrieb: > Muss denn der Sender oder Empfänger im gleichen > Netzwerk sein Nein. Aber wenn nicht, muss ein Gateway eingetragen sein.
Alles eine Frage des korrekten Routings, aber warum hast du in einem Heimnetz mehr als 1 Netzwerk?
Die Geräte müssen nicht im gleichen Netz sein. Einige Standarddienste (wie z.B. DNS) laufen über UDP. Es wird also geroutet. Ohne weitere Infos ist es schwer zu sagen warums nicht läuft. Ich würde jeweils einen Rechner mit Wireshark in jedes des Netze hängen und mal den Traffic mitschneiden. Dann siehst du ob die Pakete garnicht ankommen oder dein ESP sie nur nicht richtig interpretiert.
Hermann K. schrieb: > Ohne weitere > Infos ist es schwer zu sagen warums nicht läuft. Welche Infos möchtest du denn? > Ich würde jeweils einen > Rechner mit Wireshark in jedes des Netze hängen und mal den Traffic > mitschneiden. Dann siehst du ob die Pakete garnicht ankommen oder > dein > ESP sie nur nicht richtig interpretiert. Werde ich in Angriff nehmen Harry L. schrieb: > warum hast du in einem > Heimnetz mehr als 1 Netzwerk? eins war mir zu langweilig deswegen wollte ich paar mehr. Spaß habe das mit einer anderen Person probiert Mfg
Der Empfänger muss über eine öffentliche IP Adresse verfügen oder im gleichen Netz liegen! Die meisten Mobilfunknetze stellen private IP-Adressen zur Verfügung (z.B. 100.10.x.x). Empfänger in diesem Netz können von einem anderen Netz aus nicht erreicht werden. Damit dies möglich wäre müsste der Provider eine Portweiterleitung oder NAT einrichten. Gleiches gilt auch für Heimnetzwerke, die z.B. die private Adresse 192,168.x.x benutzen. Von Außen können keine UDP Pakete an Teilnehmer des Heimnetzwerke geschickt werden. Im Router muss konfiguriert werden, welche UDP Pakte mit welcher Portadresse an welchen internen Teilnehmer weitergeleitet werden soll. Ein Gateway zu definieren ist in der Senderichtung notwendig, damit dem Sender jene IP-Adresse bekannt wird, die dem Router gehört, über dem die UDP Pakete das eigene Netz verlassen können.
private und öffentlich IP Adressen ? da hab ich ja gar nicht dran gedacht Dann muss ich wohl noch den Router an den Kragen Danke euch.
GEKU schrieb: > (z.B. 100.10.x.x). Nein, der Bereich 'gehört' Verizon. Der 'shared' Bereich für Provider ist 100.64.0.0/10
GEKU schrieb: > Die meisten Mobilfunknetze stellen private IP-Adressen zur Verfügung > (z.B. 100.10.x.x). Horst schrub: > Nein, der Bereich 'gehört' Verizon. Der 'shared' Bereich für Provider > ist 100.64.0.0/10 Und der offensichtich gemeinte private IP-Bereich ist 10/8, also z.B. eine Adresse aus 10.10/16. Nix für ungut.
GEKU schrieb: > Der Empfänger muss über eine öffentliche IP Adresse verfügen oder im > gleichen Netz liegen! Das ist Unsinn. Wenn Sender und Empfänger nicht im gleichen Netz liegen, dann müssen die Netze nur entsprechend gekoppelt sein. Entweder mit einer Bridge (das ist der Ethernet Layer) oder mit einem Router (IP Layer). Und wenn per Router, dann muß dessen IP-Adresse als Gateway eingetragen sein. Selbstverständlich kann ein Router auch zwischen privaten Netzen routen, etwa zwischen 192.168.1.0/24 und 192.168.2.0/24
Klasse A: 1 privates Netz mit 16.777.216 Adressen; => 10.0.0.0/8 https://de.m.wikipedia.org/wiki/Private_IP-Adresse /8 bedeutet einen Netzwerkadressbereich, in dem Fall Klasse, bei dem die ersten 8 Bit das Netzwerk kennzeichnen und konstant sind. Alle Adressen 10.x.x.x gehören zum Klasse A Netzwerk, siehe Link darüber.
Es könnte helfen, wenn Franco mal die konkrete Situation beschreibt, mit IPs, Masken, Internet-Zugängen. Sonst laufen bloss die Glaskugeln heiss und trüben sich ein.
Harry L. schrieb: > Alles eine Frage des korrekten Routings, aber warum hast du in einem > Heimnetz mehr als 1 Netzwerk? Wieso denn nicht? Hat nicht jeder noch einen profesionellen Router daheim? Mit mehreren WAN-Ports mit separaten ISP-Verträgen und automatischem Fallback. Ein LAN-Segment für das ganze IoT Geraffel. Ein LAN-Segment für Sohnemann, damit seine vielleicht mal wild gewordene Büchse keinen Zugriff auf andere Rechner hat. Seine WLAN Devices hängen natürlich auch in diesem Netz. Und ein Segment für die gemäßigten Nutzer. Zusammen mit einem eigenen DNS-Server, der dann auch gleich für alle eine Blacklist der unerlaubten Namen hat und somit automatisch viel Werbung wegfällt. In einem solchen DNS-Server könnte man dann auch die lokalen IP-Adressen Segment-Übergreifend mit sinnvollen Namen hinterlegen. UDPempfaenger.beimir.daheim z.B.
Franco O. schrieb: > Wenn der ESP und der UDP Sender nicht im gleichen Netzwerk > sind erhält er die Nachricht nicht. Wenn das UDP-Paket nicht vom Sender zum ESP findet, wird der ESP es auch nicht empfangen. Sollte jetzt nicht überraschen. Dazu braucht man ein Gateway, welches die Pakete passend weiterleitet. Im gleichen Netz (Broadcast-Domain) braucht man das nicht, weil dort die Pakete automatisch (ARP) zum Ziel finden.
Axel S. schrieb: > Selbstverständlich kann ein Router auch zwischen privaten Netzen routen, > etwa zwischen 192.168.1.0/24 und 192.168.2.0/24 Wenn sie die Administrierung voll im Griff habe, dann ist es kein Problem. Bei einem Mobile Anbieter wünsche ich ihnen viel Glück! Versuchen sie einmal ihr Smartphone vom Festnetz zu pingen.
Axel S. schrieb: > Selbstverständlich kann ein Router auch zwischen privaten Netzen routen, > etwa zwischen 192.168.1.0/24 und 192.168.2.0/24 Ich habe nicht geschrieben, dass man nicht zwischen privaten Netzwerken kommunizieren kann. Bei zwei privaten Netzwerken reicht aber sende-seitig das Gateway einzustellen nicht aus! Empfangsseitig muss eine Portweiterleitung durchgeführt werden. siehe Portweiterleitung durch Router: https://de.wikipedia.org/wiki/Portweiterleitung (es geht darum, dass der Router zwischen zwei Private Netze sitzt) Auch ein VPN über zwei Fritzboxen setzt ein öffentliches Netz voraus. https://avm.de/service/vpn/praxis-tipps/vpn-verbindung-zur-fritzbox-unter-windows-einrichten-fritzfernzugang/
Horst schrieb: > GEKU schrieb: >> (z.B. 100.10.x.x). > > Nein, der Bereich 'gehört' Verizon. Der 'shared' Bereich für Provider > ist 100.64.0.0/10 Sorry, ich hatte eigentlich 10.100.x.x gemeint.
GEKU schrieb: > Bei zwei privaten Netzwerken reicht aber sende-seitig das Gateway > einzustellen nicht aus! > > Empfangsseitig muss eine Portweiterleitung durchgeführt werden. > > siehe Portweiterleitung durch Router: > https://de.wikipedia.org/wiki/Portweiterleitung > > (es geht darum, dass der Router zwischen zwei Private Netze sitzt) Unsinn. Routing ist Schicht 3. Ports sind Schicht 4. Du vermischst hier einiges. Du gehst ständig davon aus, dass hier was übers Internet oder so läuft und irgendwo NAT gemacht werden müsste. Wieso?
GEKU schrieb: > Bei einem Mobile Anbieter wünsche ich ihnen viel Glück! > Versuchen sie einmal ihr Smartphone vom Festnetz zu pingen. Bei Telefonica wird sowieso nur so etwas ähnliches wie TCP verwendet. Dort ist es zum Beispiel alltäglich, dass einmalig gesendete Pakete den Empfänger mehrfach erreichen, was dann z.B. zu den hier bekannten Doppel-Posts führt. Jeder der Online Shops programmiert, muss sich mit diesem Scheiß im Applikations-Layer beschäftigen. Dabei sollte TCP genau dieses Problem verhindern.
Md M. schrieb: > Du gehst ständig davon aus, dass hier was übers Internet oder > so läuft und irgendwo NAT gemacht werden müsste. Wieso? Rorschachtest mit eingetrübter Glaskugel.
@GEKU Wieso bringst du überhaupt Mobilfunkzugang ins Spiel? Wo war davon die Rede?
Stefanus F. schrieb: > Bei Telefonica wird sowieso nur so etwas ähnliches wie TCP verwendet. > Dort ist es zum Beispiel alltäglich, dass einmalig gesendete Pakete den > Empfänger mehrfach erreichen, Was bei TCP nicht weiter ungewöhnlich ist... > was dann z.B. zu den hier bekannten Doppel-Posts führt. ...und vom TCP Layer des Betriebssystems erledigt wird. Ein Anwendung kriegt doppelte Pakete überhaupt nicht mit. Denkbar wäre, dass ein transparenter Proxy sowas verbricht. Das hätte dann aber nichts mehr mit TCP zu tun.
GEKU schrieb: > Warten wir ab ob der TO noch seinen Testaufbau beschreibt. Eben. Genau deswegen, weil er es eben noch nicht getan hatist es Unsinn, einfach von irgendwas auszugehen.
A. K. schrieb: > ...und vom TCP Layer des Betriebssystems erledigt wird. Ein Anwendung > kriegt doppelte Pakete überhaupt nicht mit. Schön wär's, bei Telefonica funktioniert das aber eben nicht. Auch vertauschte Reihenfolge von Paketen sind bei Telefonica alltäglich. Das es besser geht, zeigen Telekom und Vodafone. Bei denen tritt dieses Problem nicht auf.
Stefanus F. schrieb: > Bei Telefonica wird sowieso nur so etwas ähnliches wie TCP verwendet. > Dort ist es zum Beispiel alltäglich, dass einmalig gesendete Pakete den > Empfänger mehrfach erreichen, was dann z.B. zu den hier bekannten > Doppel-Posts führt. Nein, mehrfach übertragene, identische TCP-Pakete werden natürlich durch den TCP/IP-Stack herausgefiltert, da dieser den Überblick hat, welche Pakete des jeweils offenen Fensters (sliding window) schon angekommen sind oder noch ausstehen. Es kommt aber trotzdem häufig zur Wiederholung ganzer HTTP-Requests. Als ich in den Logfiles eines meiner Server feststellte, dass bestimmte Zugriffe immer doppelt auftraten, und zwar einmal aus dem Netzwerk meines Kunden und kurz zuvor von einer dubiosen IP-Adresse aus einem US-amerikanischen Netz, dachte ich zunächst, es handele sich um einen Angriff. Wie sich herausstellte, verwendete mein Kunde auf seiner Firewall eine "Sicherheitssoftware" eine amerikanischen Herstellers. Jeder URL wurde von der Firewall erst einmal in die USA geschickt, dort der Inhalt abgerufen und geprüft und anschließend ein OK/nicht OK an die Firewall zurückgemeldet. Dies halte ich für ein doch eklatantes Sicherheitsproblem, zumal dieser Kunde selbst u.a. im Rüstungsbereich tätig ist. Der dortige Systemverwalter und die IT-Sicherheitsabteilung sahen aber kein Problem, denn die Firewall hatte alle geforderten Sicherheitsiegel und Zertifizierungen. Toll. > Jeder der Online Shops programmiert, muss sich mit diesem Scheiß im > Applikations-Layer beschäftigen. Dabei sollte TCP genau dieses Problem > verhindern. Dafür kann aber TCP/IP nichts, sondern so etwas liegt an solcher "Sicherheitssoftware", die alle Inhalte gleich ins Ausland schickt.
Andreas S. schrieb: > Nein, mehrfach übertragene, identische TCP-Pakete werden natürlich durch > den TCP/IP-Stack herausgefiltert, Nochmal: Sie werden nicht gefiltert. Offensichtlich modifiziert Telefonica die Pakete auf eine Art, welche genau diese Funktion kaputt macht.
Andreas S. schrieb: > Dafür kann aber TCP/IP nichts, sondern so etwas liegt an solcher > "Sicherheitssoftware", die alle Inhalte gleich ins Ausland schickt. Ähnliche Spässe sind Routine bei Bestätigungsmails für die Mailadresse bei Account-Registrierungen und dergleichen. Da ist dann ein Link zum anklicken drin, der die eigentliche Aktion auslöst. Software für Mail-Security (kann auch eine Enterprise-Firewall sein) liest die Mail mit, sieht den Link darin und "klickt" vorsorglich drauf, um zu sehen, was dann kommt. Kluge Entwickler bauen auf der Zielseite des Links einen zweiten Klick ein. Doofe nicht.
:
Bearbeitet durch User
A. K. schrieb: > > Ähnliche Spässe sind Routine bei Bestätigungsmails für die Mailadresse > bei Account-Registrierungen und dergleichen. Da ist dann ein Link zum > anklicken drin, der die eigentliche Aktion auslöst. > > Software für Mail-Security (kann auch eine Enterprise-Firewall sein) > liest die Mail mit, sieht den Link darin und "klickt" vorsorglich drauf, > um zu sehen, was dann kommt. Kluge Entwickler bauen auf der Zielseite > des Links einen zweiten Klick ein. Doofe nicht. Ach du ScheiXXe. Was bin ich froh, aus dem Homeoffice arbeiten zu dürfen und nicht mehr durch so ein "corporate network" zu müssen. Da sucht man sich doch dumm und dämlich, wenn man in so einer Umgebung einen Fehler finden will.
GEKU schrieb: > Axel S. schrieb: >> Selbstverständlich kann ein Router auch zwischen privaten Netzen routen, >> etwa zwischen 192.168.1.0/24 und 192.168.2.0/24 > > Ich habe nicht geschrieben, dass man nicht zwischen privaten Netzwerken > kommunizieren kann. Hast du: GEKU schrieb: > Der Empfänger muss über eine öffentliche IP Adresse verfügen oder im > gleichen Netz liegen! > Bei zwei privaten Netzwerken reicht aber sende-seitig das Gateway > einzustellen nicht aus! Das hängt doch ganz allein von der Netzwerk-Topologie ab. Wenn das zwei private Netze am gleichen Router sind (wovon man beim TE zu 99.9% ausgehen kann) dann kann und darf der natürlich zwischen seinen Netzen hin und her routen wie er lustig ist. Ein Problem wird das erst, wenn auf dem Weg zwischen den privaten Netzen irgendwo ein öffentliches Netz ist. Denn Router im öffentlichen Teil des Internet dürfen Pakete von oder für private Netze nicht routen. Dann (und nur dann) braucht man NAT und Portforwarding. Oder einen Tunnel. Ich habe den Eindruck, daß so wie der Arduino uns eine Schwemme von unfähigen "Programmierern" gebracht hat, uns jetzt der ESP eine Schwemme von unfähigen "Netzwerkern" bringt. <seufz> Die nächsten Schritte auf dem Eskalationspfad sind schon zu sehen: selbstfahrende Autos und automatische Kriegswaffen. <grusel>
Axel S. schrieb: > Ein Problem wird das erst, wenn auf dem Weg zwischen den privaten Netzen > irgendwo ein öffentliches Netz ist. Das war mein Problem. Dieses war nur lösbar mit SIM Karten vom gleiche Provider an beiden Enden. Bezüglich Thread ist es besser abzuwarten ob wir den Testaufbau noch erfahren. Alles andere ist Kaffeeslesen.
Ich werfe mal noch den Begriff "STUN" in den Raum, um das Thema "NAT und Portforwarding" noch etwas zu verwässern. Viel Spaß.
Hi, Ganz schön viele Antworten danke dafür! Okay Testaufbau wolltest ihr. Ist aber nicht vorhanden. Es nur das das ESP8266F Modul und das Sender Programm. Den Code hab ich gerade leider nicht zur Hand ist aber das normale UDP Beispiel von Arduino. Das Programm zum senden war 'PacketSender'. Ich hatte es einmal in meinem Netz probiert sprich PC und ESP im selben WLAN (zum testen auch nochmal ESP ins WLAN vom Nachbarn) und wie gesagt Ein Kommilitone hat es bei sich Zuhause ebenfalls probiert. Mfg
Franco O. schrieb: > Ich hatte es einmal in meinem Netz probiert sprich PC und ESP im selben > WLAN Manche WLAN Router wie z.B. die Fritzbox kennen solche Einstellungen wie "Kommunikation der Clients untereinander erlauben ja/nein". Wenn das auf "nein" steht, filtert der AP genau diese Kommunikation raus.
Andreas S. schrieb: > Angriff. Wie sich herausstellte, verwendete mein Kunde auf seiner > Firewall eine "Sicherheitssoftware" eine amerikanischen Herstellers. > Jeder URL wurde von der Firewall erst einmal in die USA geschickt, dort > der Inhalt abgerufen und geprüft und anschließend ein OK/nicht OK an die > Firewall zurückgemeldet. Dies halte ich für ein doch eklatantes Das ist nicht außergewöhnlich. Ich kenne ähnliches von z.B. TrendMicro Antivirus, welches erst einmal mit einem Hash der URL "nach Hause" telefoniert um ein Ranking für die URL bzw. deren Inhalte zu bekommen. Und wenn der zentrale Server die URL noch nicht gescannt hatte, tut er das vermutlich dann. Und so ähnlich werden wohl auch viele Webfilter von Firewalls funktionieren. Jedesmal die ganze Seite von vorne zu scannen wäre wohl zu aufwändig. Mittlerweile ist es "normal" die Untersuchung von Inhalten auch in "der Cloud" erledigen zu lassen anstatt auf der lokalen Firewall. Somit sind Zugriffe von sonstwo zu erwarten.
Stefanus F. schrieb: > Andreas S. schrieb: >> Nein, mehrfach übertragene, identische TCP-Pakete werden natürlich durch >> den TCP/IP-Stack herausgefiltert, > > Nochmal: Sie werden nicht gefiltert. Offensichtlich modifiziert > Telefonica die Pakete auf eine Art, welche genau diese Funktion kaputt > macht. Das ist schlicht nicht möglich. Jedes TCP-Paket hat eine Sequenznummer, anhand derer der Empfänger erkennt, ob er es schon empfangen hat. Und man kann die auch nicht so einfach manipulieren, da sie zwischen den beiden Endgeräten verwendet wird. Ansonsten sträuben sich einem hier ja die Haare was teilweise so geschrieben wird. Dem IP-Protokoll und Routing ist es herzlich egal, ob es private (RFC 1918) oder public IP-Adressen routet. Das eben RFC 1918 Adressen nicht im Internet geroutet werden ist eine reine Konvention. Wenn beide Seiten (auch in privaten IP Subnetzen) jeweils das richtige Gateway in ihrem jeweiligen Subnetz konfiguriert haben funktioniert das alles. Davon zu unterscheiden ist das Bridging was fast alle Heimrouter zwischen dem WLAN und dem LAN machen. Es ist das selbe Netz (meist irgendein 192.168.x.x), der Router leitet die Pakete auf Layer 2 entsprechend weiter zwischen LAN <-> WLAN. Dafür ist kein Gateway notwendig. Aber wie schon oben geschrieben, blocken einige Router per Voreinstellung die Daten zwischen mehreren WLAN Stationen.
:
Bearbeitet durch User
Stefanus F. schrieb: > Bei Telefonica wird sowieso nur so etwas ähnliches wie TCP verwendet. The internet layer software encapsulates each TCP segment into an IP packet by adding a header that includes (among other data) the destination IP address. ( https://en.wikipedia.org/wiki/Transmission_Control_Protocol )
GEKU schrieb: > Bei zwei privaten Netzwerken reicht aber sende-seitig das Gateway > einzustellen nicht aus! Bei verschiedenen Netzen muss bei allen Teilnehmern ein Gateway eingatragen werden. > Empfangsseitig muss eine Portweiterleitung durchgeführt werden. Das macht das Gateway und zwar beidseitig.
A. K. schrieb: > Nein. Aber wenn nicht, muss ein Gateway eingetragen sein. Sowas kann durchaus sinnvoll sein.
Wie funktioniert eigentlich die automatische Umsetzung von IPv6-Internet auf das IPv4-Internet? Oder sind die gar nicht miteinander verbunden?
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.