IP Subnetz prüfen

dann muss da ja in der Anzeige auch irgendwo ein Gateway auftauchen

192.168.x.y. ist per Definition ein privates Klasse C Netz mit Maske 
255.255.255.0.

Insofern glaube ich das hier nicht:
> Netzwerkadapter hat 192.168.0.2, Subnetz 255.255.0.0

Oliver

Oliver S. schrieb:
> 192.168.x.y. ist per Definition ein privates Klasse C Netz mit Maske
> 255.255.255.0.
>
> Insofern glaube ich das hier nicht:
>> Netzwerkadapter hat 192.168.0.2, Subnetz 255.255.0.0

Feste Klassen gibts schon sehr lange nicht mehr, weshalb 192.168. nicht 
auf /24 beschränkt ist. Insofern kann es auch sein, dass das Interface 
falsch definiert wurde.

svensson schrieb:
> Allerdings werden diese "privaten" Bereiche nicht gerouted, wenn der
> Router seinen Namen verdient.

Nicht ins Internet und zurück geroutet. Zwischen mehreren privaten 
Interfaces am Router darf er sehr wohl routen.

svensson schrieb:
> Und mit dem Broadcast kommst man ohnehin nicht über das Subnetz hinaus,
> da die Vermittlung zwischen Subnetzen Sache des Routers (=Gateway) ist.

Es gibt keinen Router dazwischen. Es sind Direktverbindungen. Der 
Zugriff von meinem Adapter mit größerem Adressbereich auf das Gerät mit 
eingeschränkterem läuft einwandfrei.

Martin S. schrieb:
> Irgendwie blicke ich da nicht ganz durch.

Die anderen auch nicht. Mal ein Bild, mit Angabe von IP, Maske, Gateway.

Dr. Sommer schrieb:
> Es klingt jedenfalls nach einer
> falschen Netz-Konfiguration; da kann man auf Anwendungsebene wenig
> machen.

Die Geräte, die am Netzadapter angeschlossen werden können, können 
entweder den IP-Adressbereich 10.6.3.x, 10.6.2.x oder 192.168.0.x sowie 
192.168.1.x haben. Die in den geräten konfigurierte Subnetzmaske ist 
entweder 255.255.255.0 oder 255.255.0.0.

Das hat nichts mit falsch konfiguriert zu tun, denn jenachdem, wie der 
Adapter konfiguriert ist, kann auf die Geräte entweder zugegriffen 
werden, oder eben nicht. Antworten auf den UDP Broad/Multicast tun sie 
alle, nur ist - je nach Adaptereinstellungen - eben gar keine Verbindung 
möglich.

> Die Anforderung "die Anwendung soll auch bei kaputtem Netzwerk
> kommunizieren können" ist nicht erfüllbar...

Soll ja auch gar nicht. Ich möchte nur eine Vorabprüfung implementieren, 
die es erlaubt, vorweg zu sagen, ob es gehen kann, oder nicht. Um mehr 
geht es mir nicht.

Im Zuge dessen hat mich verwirrt, welche Subnetzmaske für die Prüfung 
herangezogen wird. Die des Netzwerkadapters oder die des Gerätes. 
Limitierende Komponente ist hier der Netzwerkadapter.

A. K. schrieb:
> Martin S. schrieb:
>> Irgendwie blicke ich da nicht ganz durch.
>
> Die anderen auch nicht.

Schön. Dann geht's nicht nur mir so :-)

> Mal ein Bild, mit Angabe von IP, Maske,

siehe oben.

> Gateway.

Gibt's nicht.

Martin S. schrieb:
> Die Funktion "IsInSameSubnet" akzeptiert aber nur eine Subnetzmaske.
> Aber müssen nicht beide berücksichtigt werden?

Das ist nicht nötig, denn wenn im gleichen IP-Netz an verschiedenen 
Geräten/Interfaces verschiedene Masken definiert sind, dann hat man 
etwas falsch gemacht.

Martin S. schrieb:
>> Mal ein Bild, mit Angabe von IP, Maske,
>
> siehe oben.

Wo?

Dr. Sommer schrieb:
> Das kann man den Adressen nicht ansehen. Du weißt ja nicht was für
> Router dazwischen hängen und welche Routing-Tabellen diese haben.

Kein Router. Direktverbindung. Höchstens ein Switch. Oder ein Hub. Kein 
Internet, kein DHCP, kein DNS, kein ...

Einfache Regel: Wer eine Frage stellt und dabei seinen Sturkopf 
durchsetzt, der reduziert seine Chancen auf eine qualifizierte Antwort.

Im Anhang mal die Netzwerkkonfiguration sowie die beiden Geräte 
ausgelesen.

A. K. schrieb:
> dabei seinen Sturkopf
> durchsetzt

Welchen Sturkopf? Was hättest Du gerne noch als Informationen?

Ich habe eine einfache Frage gestellt, bei der es vollkommen egal ist, 
welche Geräte, wie konfiguriert sind, denn die Frage war vielleicht mit 
praktischen Bezug, aber ganz allgemein zu verstehen.

Es ist nunmal leider in Foren oft so, dass der Kern des Gespräches 
irgendwohin abwandert und Details diskutiert werden, die gar nichts zur 
Sache tun. Was interessiert es für das Problem, welcher Kategorie 
welcher Adressbereich angehört?

Dr. Sommer schrieb:
> Wie passiert denn sowas? Das ist m.W. gar nicht erlaubt
> (Fehlkonfiguration). Da muss mindestens ein Router zwischen sein. Kein
> Wunder dass das nicht funktioniert.

svensson schrieb:
> zwei unterschiedliche Subnetzmasken bedeuten immer, daß die Geräte in
> unterschiedlichen Subnetzen sind.

Martin S. schrieb:
> Es gibt keinen Router dazwischen. Es sind Direktverbindungen.


Du solltest dein Konzept nochmals überdenken...

Oliver

Entweder 10.6.x.y/16 oder 10.6.3.x/24. Nicht sowohl als auch.

Zwischen 192.168.1.154/24 und 10/irgendwas gibts keine Kommunikation 
ohne Gateway. Grundkurs IP-Networking empfohlen.

Martin S. schrieb:
> bei der es vollkommen egal ist, welche Geräte, wie konfiguriert sind,

Nö.

Dr. Sommer schrieb:
> In diesem Spezialfall vergleiche einfach ob die Subnetzmasken gleich
> sind und "IP-Adresse-Gerät & maske" == "IP-Adresse-Adapter & maske"
> ist.

Obwohl die Verbindung (siehe Bilder) funktioniert, würde bei der Prüfung 
eine Verbindung als nicht möglich deklariert.

A. K. schrieb:
> Martin S. schrieb:
>> bei der es vollkommen egal ist, welche Geräte, wie konfiguriert sind,
>
> Nö.

Doch. Für eine Softwareprüfung ist das vollkommen egal.

JJ schrieb:
> alle anderen werden über ein
> Gateway erreicht.

Ja aber welchen? Ich hab hier ja keinen und trotzdem geht die 
Kommunikation trotz der unterschiedlichen Subnetzmaske.

Also kommen da irgendwoher Routing informationen?!

Die Frage mit dem IP Check ist ja soweit beantwortet. Aber neugierig, 
warum es trotzdem geht, bin ich jetzt auch.

Martin S. schrieb:
> Obwohl die Verbindung (siehe Bilder) funktioniert, würde bei der Prüfung
> eine Verbindung als nicht möglich deklariert.

Und das ist völlig korrekt. Grundkurs IP-Networking empfohlen.

Als Anfänger hatte ich einem Gerät mal die Adresse 255.255.255.255 
gegeben. Auch da hatte die Verbindung funktioniert. ;-)

A. K. schrieb:
> Als Anfänger hatte ich einem Gerät mal die Adresse 255.255.255.255
> gegeben. Auch da hatte die Verbindung funktioniert. ;-)

Und das hat funktioniert?! Lustig :-)

Ich verstehe nun tatsächlich nicht, warum es bei mir funktioniert, 
obwohl das Subnetz ein anderes ist. Also entweder wird irgendwo die 
Anfrage ins andere Subnetz umgebogen, oder es gibt Ausnahmen von der 
Regel.

Martin S. schrieb:
> Und das hat funktioniert?! Lustig :-)

Ist schon eine Weile her, war ein freies TCP/IP für DOS. Gab natürlich 
einen hübschen Traffic im Netz.

> Ich verstehe nun tatsächlich nicht, warum es bei mir funktioniert,

Hast du mehrere verschiedene IP-Netze auf dem gleichen Ethernet?

Martin S. schrieb:
> Es gibt keinen Router dazwischen. Es sind Direktverbindungen. Der
> Zugriff von meinem Adapter mit größerem Adressbereich auf das Gerät mit
> eingeschränkterem läuft einwandfrei.

Da wird nichts heimlich „umgebogen“. In der Richtung sieht der Adapter 
ja nur ein Subnetz mit Maske 255.255.0.0, und in dem liegt auch die 
Adresse 192.168.0.100. Ergo ist für den alles in Ordnung, ganz ohne 
Router.

Die andere Richtung tuts halt nicht.

Oliver

Oliver S. schrieb:
> Die andere Richtung tuts halt nicht.

Aber die schickt daten auf die Anfrage hin zurück, und die kommen auch 
an?!

Ingo schrieb:
> sondern
> ein arp request ausgelöst

Das heißt dann aber, dass ich einen entsprechenden Eintrag in der ARP 
Tabelle von Windows finden müsste, oder?

Martin S. schrieb:
> Ich verstehe nun tatsächlich nicht, warum es bei mir funktioniert,
> obwohl das Subnetz ein anderes ist. Also entweder wird irgendwo die
> Anfrage ins andere Subnetz umgebogen, oder es gibt Ausnahmen von der
> Regel.

Welche Adressen haben die Teilnehmer?

vn n. schrieb:
> Welche Adressen haben die Teilnehmer?

Ich hab die Bilder weiter oben mit den Geräteadressen gepostet.

imonbln schrieb:
> Wie schon mehrfach gesagt, das es Funktioniert ist purer Zufall und,
> wahrscheinlich auch nur wenn Kommunikation im 24 Subnetz begonnen wird.

Ich glaube Dir das sehr gerne, würde es aber verstehen wollen.

Hier mal ein Auszug aus der Kommunikation. Diese beginnt von 10.6.3.10 
bzw. 192.168.1.10 und schickt eine definierte Anfrage an alle Geräte. 
Auf diese antworten diese dann, mit einer Identifikation (im UDP Paket). 
Man sieht auch einen Zugriff via ARP Protkoll - den habe ich bisher auch 
nicht wirklich verstanden.

Bin für Erklärungen offen :-)

Martin S. schrieb:
> vn n. schrieb:
>> Welche Adressen haben die Teilnehmer?
>
> Ich hab die Bilder weiter oben mit den Geräteadressen gepostet.

Warum auch immer man sowas als Bild postet...

BTT:
An der Subnetzmaske erkennt der Teilnehmer, ob das Gegenüber im eigenen 
Netz ist (und er direkt mit ihm reden kann), oder ob die Kommunikation 
über ein Gateway geleitet werden muss.
10.6.3.10/16 nach 10.6.3.39: funktioniert, das gemeinsame Netz ist 
10.6/16
10.6.3.39/24 nach 10.6.3.10: funktioniert, das gemeinsame Netz ist 
10.6.3/24

Stricken wir das ganze etwas weiter, und lassen wir die Subnetzmaske so 
wie bei dir, ändern aber die Adresse des Gerätes:
10.6.3.10/16 nach 10.6.4.39: funktioniert, das gemeinsame Netz ist 
10.6/16
10.6.4.39/24 nach 10.6.3.10: funktioniert nicht, das gemeinsame Netz aus 
Sicht des Senders ist 10.6.4/24, 10.6.3.10 liegt da nicht drinnen

Ändern wir jetzt auch die Subnetzmaske des Gerätes so, wie sie 
eigentlich gehört:
10.6.3.10/16 nach 10.6.4.39: funktioniert, das gemeinsame Netz ist 
10.6/16
10.6.4.39/16 nach 10.6.3.10: funktioniert, das gemeinsame Netz ist 
10.6/16

Man sieht, die Kommunikation ist nicht darauf angewiesen, dass beide 
Teilnehmer die gleiche Netzmaske haben. Es reicht, wenn die beiden 
Adressen aus Sicht des Teilnehmers mit dem kleinsten konfigurierten Netz 
(kleinste Anzahl an Nullen in der Netzmaske) im gleichen Netz liegen.
Unterschiedliche Netzmasken sind allerdings sehr unschön, und können zu 
langwieriger Fehlersuche führen, weshalb sie im Idealfall zu unterlassen 
sind.

1

// check if the destination address is on the local network

2

if (packet.destination_ip & host.mask == host.ip & host.mask){

3

    // destination in local network

4

}

5

else {

6

    // destination ni other network, use gateway

7

}

imonbln schrieb:
> Wie schon mehrfach gesagt, das es Funktioniert ist purer Zufall und,
> wahrscheinlich auch nur wenn Kommunikation im 24 Subnetz begonnen wird.
> Vielleicht "hilft" hier der arp cache des OS das es zu gehen scheint.

Bullshit.
Ja, es ist unschön und fehleranfällig, aber mit den konkret gewählten 
Adressen kein Zufall! In vielen anderen Szenarien funktioniert es 
natürlich nicht, oder (implementierungsabhängig) zufällig, aber dieses 
ist kein solches!

Würde jeder bei den Themen bleiben, wo er sich auskennt...

Martin S. schrieb:
> Ich glaube Dir das sehr gerne, würde es aber verstehen wollen.

Er liegt falsch, musst du also nicht verstehen.

Martin S. schrieb:
> Man sieht auch einen Zugriff via ARP Protkoll - den habe ich bisher auch
> nicht wirklich verstanden.

ARP löst die IP-Adresse in eine MAC-Adresse auf.

Hi,

vielen Dank für Deine ausführliche Erklärung.

Was mich jetzt an dem Log vom Wireshark interessiert: Dort steht "Who 
has 192.168.1.154? Tell 10.6.3.39" (das ist die erste IP des Adapters) - 
biegt da jetzt Windows den Datenstrom um? Denn eigentlich kann ja 
192.168.1.154 den Empfänger 10.6.3.39 gar nicht erreichen, da komplett 
falsches Subnetz, oder?

Dass die unterschiedlichen Subnetzmasken sch**** sind, ist mir auch 
klar. Allerdings lässt sich das nicht so ohne weiteres lösen. Dafür 
wären Firmwareupdates der Geräte notwendig, die auf Grund von 
Kundenzertifizierungen aber sehr langwierig sind (> 1 Jahr). Daher muss 
ich damit leben und verstehen, was genau passiert, und wie ich meinen 
Teil so gestalten muss, dass es geht, auch wenn mir die Lösung nicht 
gefällt.

Interssanterweise antworten beide Geräte auf den UPD-Broadcast egal von 
welcher Adapter IP er gesendet wird. Ist das jetzt nur bei mir so, weil 
ich nur eine physikalische Netzwerkhardware habe oder ist das eine 
Windows-Eigenheit? Es wäre ja furchtbar, wenn alle Geräte der Welt auf 
einen Broadcast antworten würde, wenn ich einen auf die Netzwerkkarte am 
Internet schicken würde :-)

svensson schrieb:
> Langsam dämmert da was: Du möchtest einen Netzwerkadapter für
> verschiedene Netze benutzen? Dabei wird aber immer nur ein Netzwerk
> gleichzeitig verwendet.

Ich dachte das wird aus der oben gezeigten Netzwerk-Konfiguration klar?!

svensson schrieb:
> Allerdings sollte diese Konfiguration der Netzwerkkarte vom "normalen"
> Netzwerk ferngehalten werden.

Das läuft über zwei getrennte physikalische Netzwerkadapter.

Martin S. schrieb:
> Dort steht "Who has 192.168.1.154? Tell 10.6.3.39"
> (das ist die erste IP des Adapters) - biegt da jetzt Windows
> den Datenstrom um?

Windows sucht nach 192.168.1.154 und falls den jemand kennt, soll er es 
dir (10.6.3.39) sagen. Falls da tatsächlich jemand drauf antwortet, 
kannst du lokal kommunizieren. Da kein Gateway vorhanden ist, ist das 
eine möglicherweise sinnvolle Fallback-Lösung.

> Denn eigentlich kann ja 192.168.1.154 den Empfänger
> 10.6.3.39 gar nicht erreichen, da komplett falsches Subnetz, oder?

Wenn kein Gateway vorhanden ist, die Adressen aber eigentlich über ein 
Gateway gehen müssten, kann man ja trotzdem versuchsweise in der 
Umgebung fragen. Würde mich nicht wundern, wenn Windows das tut.

Es gibt auch einige Netzwerkgeräte (ATAs und so), die mit einer 
statischen Konfiguration hochkommen und mit so einem Fallback kann man 
die dann konfigurieren, ohne seine eigene Netzwerkkonfiguration komplett 
über den Haufen schmeißen zu müssen.

Martin S. schrieb:
> Dem Beitrag folgend möchte ich die Adressen prüfen.
>
> Netzwerkadapter hat 192.168.0.2, Subnetz 255.255.0.0
> Gerät hat 192.168.0.100, Subnetz ist 255.255.255.0
>
> Die Funktion "IsInSameSubnet" akzeptiert aber nur eine Subnetzmaske.
> Aber müssen nicht beide berücksichtigt werden?
>
> Irgendwie blicke ich da nicht ganz durch.

https://www.heise.de/netze/tools/netzwerkrechner/