muss UDP Sender und Empfänger im gleichen Netzwerk sein?

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.

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

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.

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.

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?

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.

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:
> 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.

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>

Ich werfe mal noch den Begriff "STUN" in den Raum, um das Thema "NAT und 
Portforwarding" noch etwas zu verwässern. Viel Spaß.

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.

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.

Neugieriger schrieb:
> Oder sind die gar nicht miteinander verbunden?

Ebendies.