[idUDPClient] Broadcast auf allen Interfaces raus senden

[gsh]

hat noch jemand eine idee dazu?

[gsh]

SRY leute muss mich entschuldigen bin gerade draufgekommen das der Broadcast auf allen Interfaces raus geht... ABER er geht immer mit der IP Adresse vom ersten Adapter weg.

Das Packet geht also über mein wirkliches interface mit der hamachi source IP raus. Das ist zum antworten auf der gegenseite natürlich gar nicht gut. Ist das ein konfigurationsfehler von mir oder ein Bug in den Indys?

[gsh]

ich hab mich jetzt mit den bindings ein bisschen rumgespielt aber ich schafe es einfach nicht das der broadcast vom normallen interface mit der richtigen source IP rausgeht

Hat das Indy Projekt einen Bug Tracker (hab nur einen premium support gefunden)?

[gsh]

[Assertor]

Hi,

Konfigurationsfehler Du mußt die IP festlegen, wenn Du die ausgehende IP nicht automatisch (vom System) bestimmt haben willst:

Delphi-Quellcode:

IdUDPClient1.BoundIP := '192.168.100.1'; // muß eine gültige IP sein
IdUDPClient1.Broadcast('Hello World by Indy', 12345);

Der Broadcast selbst wird natürlich auf allen Adaptern gesendet, da er an die 255.255.255.255 geht. Ein Broadcast halt. Gerade getestet, das geht einwandfrei. Also kein Grund, ein Indy Bug Report zu senden

Gruß Assertor

[gsh]

Zitat von Assertor:

Hi,

kein Grund für einen Bug-Report. Du mußt die IP festlegen, wenn Du die ausgehende IP nicht automatisch (nach System-Reihenfolge) bestimmt haben willst:

Delphi-Quellcode:

IdUDPClient1.BoundIP := '192.168.100.1'; // muß eine gültige IP sein
IdUDPClient1.Broadcast('Hello World by Indy', 12345);

Der Broadcast selbst wird natürlich auf allen Adaptern gesendet, da er an 255.255.255.255 geht. Ein Broadcast halt. Gerade getestet, das geht einwandfrei. Also kein Grund, ein Indy Bug Report zu senden

Gruß Assertor

Danke für deine Antwort

das Problem ist das der Broadcast über den Adapter mit der jeweiligen Source-IP rausgehen muss.
Wenn ich jetzt wie du beschrieben hast die IP manuell setze dann geht der Broadcast auf allen Adapter mit der manuel festgelegten Source IP raus. Was aber wieder beim ersten Adapter schlecht ist.

Zum besseren Verständniss ein beispiel: (Packet geht mit folgender Source-IP raus)

So sieht es ohne manuelle IP aus

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 5.x.x.x

Wenn ich die IP manuel auf 192.168.0.x ändern

Hamachi-Adapter: 192.168.0.x
LAN-Adapter: 192.168.0.x

So sollte es aussehen

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 192.168.0.x

[Assertor]

Hi,

Zitat von gsh:

das Problem ist das der Broadcast über den Adapter mit der jeweiligen Source-IP rausgehen muss.
Wenn ich jetzt wie du beschrieben hast die IP manuell setze dann geht der Broadcast auf allen Adapter mit der manuel festgelegten Source IP raus. Was aber wieder beim ersten Adapter schlecht ist.

Zum besseren Verständniss ein beispiel: (Packet geht mit folgender Source-IP raus)

So sieht es ohne manuelle IP aus

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 5.x.x.x

Wenn ich die IP manuel auf 192.168.0.x ändern

Hamachi-Adapter: 192.168.0.x
LAN-Adapter: 192.168.0.x

So sollte es aussehen

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 192.168.0.x

Aber das ist kein Broadcast. Beim Broadcast geht es ja gerade darum, daß ohne die Clients zu kennen mit einem festen Endpunkt (also wir als Sender) etwas an alle rausschicken. Die Clients bzw. Empfänger des Broadcasts selbst entscheiden dann, was und ob sie mit den Informationen machen.

Du kannst meines Wissens nicht automatisch den Broadcast mit abweichenden Source-IPs senden. Das geht nur in dem Du durch die Liste der lokalen IP Adressen iterierst und dann für jede IP einen Broadcast sendest (der wieder über alle Adapter rausgeht).

Das wären also bei 3 Adaptern: 3 x 3 Broadcasts

Aber das führt die ganze Logik eines Broadcasts ad absurdum. An sich ist es dann Aufgabe des Clients bzw. des VPN Tunnels hier eine geeignete Route zu finden, mit der man den Sender kontaktiert. Wenn das nicht geht, schlägt die Verbindung entsprechend fehl.

Im Falle eines normalen VPN (Win2003/2008 Server) über L2TP/PPTP würde meinetwegen der Broadcast von Source 192.168.100.1 über den VPN-Tunnel (Serverseite 10.0.0.1) an den VPN-Client (10.0.0.2) an den Rechner 192.168.100.100 gehen. Wenn jetzt der Client 192.168.100.100 den Broadcast empfängt und an 192.168.100.1 antworten will, ist der (VPN)-Router für die Durchleitung mittels des 10.0.0.x Netzwerkes zuständig.

Das kommt aber auch sehr auf den VPN-Tunnel an. Bei einfachen Sachen werden die Subnetze nicht vollständig verbunden, sondern wird NAT verwendet.

So gesehen, haben es die Hamachi-Entwickler schon richtig gemacht: Damit die Programmierer nicht in diese Falle laufen, hat der Adapter die höchste Routing-Priorität und sendet über 5.0.0.x/8 - dann antwortet der Broadcast-Client an diese IP und der Server erhält die Antwort. Dabei muß der Client natürlich auch wieder über eine 5.0.0.x gebunden sein.

Wenn jetzt Hamachi aus ist und der Adapter trotzdem läuft (und Priorität hat) gehen halt die Packete verloren. Das ist dann aber ein Problem der Hamachi Software. Logisch läßt sich das nicht anders lösen befürchte ich...

Gruß Assertor

[gsh]

Ich habe das Gefühl wir reden aneinander vorbei

Natürlich ist der Broadcast dafür da ein unbekanntes Ziel zu finden. Dieses Ziel sollte dann aber wissen wohin es das Antwort Packet hinschicken soll.
Um von dem VPN Beispiel wegzugehen bzw. Hamachi nicht die Schuld zu geben nehm ich mal ein anderes Beispiel:

PC1 <--> PC2 <--> PC3 (PC1 kann nur mit PC2 reden, PC3 kann nur mit PC2 reden, PC2 mit beiden)

PC1:
LAN: IP: 192.168.1.100

PC2: (zwei Netzwerkadapter)
LAN1: Höhere Priorität, IP: 192.168.1.200
LAN2: Niedrigere Priorität, IP: 192.168.2.200

PC3:
LAN: IP: 192.168.2.100

Wenn PC2 jetzt einen Broadcast auf allen Adapter sendet (wie du richtig gesagt hast auch der Sinn der Sache ist), dann wird (ohne spezielle Config) die Source IP 192.168.1.200 verwendet. PC1 filtert die Source IP heraus und kann nun ein Antwort Packet an PC2 schicken. PC3 erhält das Packet zwar auch kann aber keine Antwort schicken da die Ziel Adresse (192.168.1.200) für Ihn nicht erreichbar ist.

Wenn ich die IP zum senden explicit auf 192.168.2.200 setze dann würde das ganze gleich sein nur umgekehrt. (PC1 könnte nicht zurücksenden, PC3 schon).

Einen Broadcast für jede IP zu versenden ist auch ihn meinen Augen nicht zielführend.

Ich weiß nicht genau wie ihr diese Broadcast Routine implementiert habt und deshalb wäre es interessant zu wissen ob die Indys alle Adapter selber durchgehen und dann bei jedem Adapter einen Broadcast raus senden oder ob die diese Aufgabe von einer tieferen Ebene erledigt wird?

[Assertor]

Hi,

Zitat von gsh:

Ich habe das Gefühl wir reden aneinander vorbei

Mag sein, bin gerade am Arbeiten

Zitat von gsh:

PC1 <--> PC2 <--> PC3 (PC1 kann nur mit PC2 reden, PC3 kann nur mit PC2 reden, PC2 mit beiden)

PC1:
LAN: IP: 192.168.1.100

PC2: (zwei Netzwerkadapter)
LAN1: Höhere Priorität, IP: 192.168.1.200
LAN2: Niedrigere Priorität, IP: 192.168.2.200

PC3:
LAN: IP: 192.168.2.100

Wenn PC2 jetzt einen Broadcast auf allen Adapter sendet (wie du richtig gesagt hast auch der Sinn der Sache ist), dann wird (ohne spezielle Config) die Source IP 192.168.1.200 verwendet. PC1 filtert die Source IP heraus und kann nun ein Antwort Packet an PC2 schicken. PC3 erhält das Packet zwar auch kann aber keine Antwort schicken da die Ziel Adresse (192.168.1.200) für Ihn nicht erreichbar ist.

Wenn ich die IP zum senden explicit auf 192.168.2.200 setze dann würde das ganze gleich sein nur umgekehrt. (PC1 könnte nicht zurücksenden, PC3 schon).

Ja, richtig - aber das Problem hat nichts mit Indy oder Delphi zu tun. Das ist Netzwerktechnik Sowas wird entweder über die 1) Subnetzmaske (Subnetting/Supernetting) oder 2) Routen/Forwarding gelöst (letzteres wäre nur am PC2 möglich).

Das ist ja das bekannte Spiel wenn man LANs verbindet: Wenn alle Rechner aus 192.168.0.0 - 192.168.255.255 sich "sehen" können müssen, muß die Netzmaske 255.255.0.0 sein. Mit der üblichen 255.255.255.0 wären z.B. 192.168.100.x und 192.168.200.x nicht im gleichen Subnetz.

Es gäbe auch noch die o.g. Directed Broadcasts, die aber in RFC2644 wegen DoS-Attacken per Default nicht mehr von Routern weitergeleitet werden (sollen).

Als Problem sehe ich auch, daß Ethernet-Broadcast mit der Zieladresse 255.255.255.255 von Routern nicht weitergeleitet werden. Dann müßte man in Richtung Multicast gehen.

Zitat von gsh:

Einen Broadcast für jede IP zu versenden ist auch ihn meinen Augen nicht zielführend.

Ich weiß nicht genau wie ihr diese Broadcast Routine implementiert habt und deshalb wäre es interessant zu wissen ob die Indys alle Adapter selber durchgehen und dann bei jedem Adapter einen Broadcast raus senden oder ob die diese Aufgabe von einer tieferen Ebene erledigt wird?

Indy durchläuft die Adapter nicht selbst. Unter Windows läuft das im Endeffekt über die WinSocks.

Aber zurück zu Deinem Problem, geh das anders an: Der Broadcast sollte unabhängig von der Source-IP überall ankommen (ist ja eben ein 255.255.255.255 Broadcast wenn kein BoundIP vorliegt). Die Source-IP ist für den Broadcast vollkommen egal - der Client kann ja seinerseits mit einem Broadcast antworten und teilt seine IP mit. Das kann man auch schön in ein kleines Datenpacket/format (Record streamen) packen. Vielleicht noch verschlüsseln und gut ist.

Ich verstehe einfach noch nicht, was das genaue Problem ist - das ist alles mit Netzwerktechnik lösbar und hat wenig speziell mit Indy oder sogar Windows zu tun. Das ist nicht böse gemeint. Das ein VPN-Tunnel bzw. -Router Broadcasts überträgt, hängt von dessen Einstellungen ab. Genauso das entsprechende Routing.

Kannst Du etwas genauer beschreiben, was Du exakt machen möchtest (falls ich es überlesen habe)?

Gruß Assertor

[gsh]

Zitat von Assertor:

Mag sein, bin gerade am Arbeiten

Ich auch

Zitat von Assertor:

Als Problem sehe ich auch, daß Ethernet-Broadcast mit der Zieladresse 255.255.255.255 von Routern nicht weitergeleitet werden. Dann müßte man in Richtung Multicast gehen.

Das wäre nicht schlimm ... Aber dies könnte man auf einem "guten" Router auch weiterleiten.

Zitat von Assertor:

Ich verstehe einfach noch nicht, was das genaue Problem ist - das ist alles mit Netzwerktechnik lösbar und hat wenig speziell mit Indy oder sogar Windows zu tun. Das ist nicht böse gemeint. Das ein VPN-Tunnel bzw. -Router Broadcasts überträgt, hängt von dessen Einstellungen ab. Genauso das entsprechende Routing.

Kannst Du etwas genauer beschreiben, was Du exakt machen möchtest (falls ich es überlesen habe)?

Ok ich versuche es noch mal genau zu erklären:

Ich möchte das sich mein Programm selber im Netzwerk finden kann. In den meisten Fällen wird es wahrscheinlich in einer einfachen Netzwerk umgebung sein (Privates Netzwerk) wo alle Computer im gleichen Subnetz sind. Bei Firmen die das dann auch über größere Netzwerke legen wollen müssen halt die Router so konfigurieren das die diese Broadcasts durchlassen (Dies ist aber nicht mein Problem).
Zurzeit habe ich das Problem so gelöst:
Sobald mein Programm startet (und danach alle 5 min) sendet es einen UDP Broadcast an 255.255.255.255. Wenn auf einem anderen PC dieses Packet empfangen wird dann sendet dieser PC einen Unicast an den ersten PC. Danach wissen beide von einander und können dann später mit einander komunizieren. Die IP Adresse von dem Gegenüber PC erhalten sie im Moment eben über die Source-IP.
Das Konzept funktioniert auch super solange nur 1 Interface auf jedem Computer existiert. Sobald aber mehrere Interfaces und somit mehere Source IP Adressen vorhanden sind gibt es eben die oben beschriebenen Probleme.

Ich hoffe du weißt jetzt was ich erreichen will.
Noch mal danke das du mir hilfst