mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik muss UDP Sender und Empfänger im gleichen Netzwerk sein?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Franco O. (comsys)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Franco O. schrieb:
> Muss denn der Sender oder Empfänger im gleichen
> Netzwerk sein

Nein. Aber wenn nicht, muss ein Gateway eingetragen sein.

Autor: Harry L. (mysth)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Alles eine Frage des korrekten Routings, aber warum hast du in einem 
Heimnetz mehr als 1 Netzwerk?

Autor: Hermann K. (r2d2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wangnick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TTL nicht vergessen!

LG, Sebastian

Autor: Franco O. (comsys)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: GEKU (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Franco O. (comsys)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: g457 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: MagIO2 (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: GEKU (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: GEKU (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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/

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Md M. (Firma: Potilatormanufaktur) (mdma)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Md M. (Firma: Potilatormanufaktur) (mdma)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@GEKU Wieso bringst du überhaupt Mobilfunkzugang ins Spiel? Wo war davon 
die Rede?

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Md M. schrieb:
> Unsinn

Warten wir ab ob der TO noch seinen Testaufbau beschreibt.

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Md M. (Firma: Potilatormanufaktur) (mdma)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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>

Autor: GEKU (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

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

Autor: Franco O. (comsys)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus M. (adrock)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus M. (adrock)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Wiki P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 )

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mein Senf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Nein. Aber wenn nicht, muss ein Gateway eingetragen sein.

Sowas kann durchaus sinnvoll sein.

Autor: Neugieriger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie funktioniert eigentlich die automatische Umsetzung von IPv6-Internet 
auf das IPv4-Internet? Oder sind die gar nicht miteinander verbunden?

Autor: A. K. (prx)
Datum:

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

Ebendies.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.