Hallo,
bisher habe ich (anscheinend) in dem Irrglauben gelebt, dass IP-Pakete (UDP, ICMP), wenn man sie an die ,,Broadcast''-Adresse 255.255.255.255 schickt, auf *ALLEN* physikalischen Netzwerkkarten ausgesendet werden...
Dem scheint allerdings bei genauem hinschauen nicht so zu sein.
Das ,,Broadcast''-Paket kommt unter Linux im besten Falle auf einem der verfügbaren Interface heraus. Hat man keine Default-Route oder womöglich 255.255.255.255 nicht direkt in der Routing-Tabelle eingetragen, wird das Paket gar nicht versendet und man bekommt ,,Network unreachable''.
(Im Prinzip ist das ja auch logisch, wenn nix in der Rouring-Tabelle steht, weiß er auch nicht wohin damit)
Aber irgendwie habe ich mir bisher eingebildet das soetwas ginge?
So wie es aussieht, gibt es also unter Linux keine einfache/automatische Möglichkeit ein Pakete auf allen n-Interfacen auszusenden (es sei den man sendet es n-mal per Hand).
(Auch wenn es fast Off-Topic ist, unter Windows scheint das ganze anders gelöst zu sein. Dort existiert per Default eine 255.255.255.255-Route für jedes Network-Device und der IP-Stack scheint auch dafür zu sorgen, dass ein Broadcast-Paket dann auf allen Geräten gesendet wird)
Hat jemand da andere Erfahrungen gemacht, kann man vielleicht in /proc oder /sys etwas einstellen?
Viele Grüße! Marcus
On Friday 28 August 2009, Marcus Obst wrote:
bisher habe ich (anscheinend) in dem Irrglauben gelebt, dass IP-Pakete (UDP, ICMP), wenn man sie an die ,,Broadcast''-Adresse 255.255.255.255 schickt, auf *ALLEN* physikalischen Netzwerkkarten ausgesendet werden...
Dem scheint allerdings bei genauem hinschauen nicht so zu sein.
Korrekt. 255.255.255.255 ist der Link-Level-Broadcast bei IPv4. Das bedeutet der Rechner hat keine Ahnung auf welcher Karte er das Paket rausschicken soll. Du musst es ihm sagen.
Das ,,Broadcast''-Paket kommt unter Linux im besten Falle auf einem der verfügbaren Interface heraus. Hat man keine Default-Route oder womöglich 255.255.255.255 nicht direkt in der Routing-Tabelle eingetragen, wird das Paket gar nicht versendet und man bekommt ,,Network unreachable''.
Woher soll er auch wissen was Du willst?
(Im Prinzip ist das ja auch logisch, wenn nix in der Rouring-Tabelle steht, weiß er auch nicht wohin damit)
Aber irgendwie habe ich mir bisher eingebildet das soetwas ginge?
So wie es aussieht, gibt es also unter Linux keine einfache/automatische Möglichkeit ein Pakete auf allen n-Interfacen auszusenden (es sei den man sendet es n-mal per Hand).
Du musst auf jedes Interface einzeln senden.
(Auch wenn es fast Off-Topic ist, unter Windows scheint das ganze anders gelöst zu sein. Dort existiert per Default eine 255.255.255.255-Route für jedes Network-Device und der IP-Stack scheint auch dafür zu sorgen, dass ein Broadcast-Paket dann auf allen Geräten gesendet wird)
Windows-Routing ist ja auch ein Trauerspiel. Die Jungens in Redmond lesen die Standards, verstehen sie nicht, fragen niemand, implementieren irgendwas...
Hat jemand da andere Erfahrungen gemacht, kann man vielleicht in /proc oder /sys etwas einstellen?
Nicht direkt Erfahrung, aber eine kurze Suche in den Man-Pages erzielt folgende Empfehlungen:
man 2 bind man 2 socket man 2 setsockopt man 7 socket (insb. SO_BINDTODEVICE, SO_BROADCAST)
Bei Ping sind das die -b und -I Optionen.
Ganz nebenbei: wieso willst du auf general Broadcast arbeiten? Ich kenne nicht allzu viele Szenarien in denen das sinnvoll ist.
Und Tipp: falls es eine lokale Service-Discovery ist: arbeite doch gleich mit IPv6, da kannst Du Dir einen Link-Local-Multicast (ff02::...) reservieren und kannst viel freier arbeiten als bei IPv4.
Konrad
Am Fri den 28 Aug 2009 um 03:13:44PM +0200 schrieb Marcus Obst:
Hallo,
bisher habe ich (anscheinend) in dem Irrglauben gelebt, dass IP-Pakete (UDP, ICMP), wenn man sie an die ,,Broadcast''-Adresse 255.255.255.255 schickt, auf *ALLEN* physikalischen Netzwerkkarten ausgesendet werden...
...
(Auch wenn es fast Off-Topic ist, unter Windows scheint das ganze anders gelöst zu sein. Dort existiert per Default eine 255.255.255.255-Route für jedes Network-Device und der IP-Stack scheint auch dafür zu sorgen, dass ein Broadcast-Paket dann auf allen Geräten gesendet wird)
Letzteres kann ich nicht bestätigen, man muß auch dort auf jedem Interface seinen Broadcast absetzen. Die robusteste Lösung ist, das Paket auf allen Interfaces zu senden und anschließend alle mehrfach empfangenen Antworten auszusortieren (die Antwort wird von jedem Interface empfangen).
In unserem Fall ging es darum, einen Dienst bzw. ein Gerät zu erkennen, ähnlich wie das Konrad schon geschrieben hat. Ein schöner Implementierungsfehler ist in diesem Zusammenhang das Gerät mittels eines normalen Datagramms an die Absenderadresse antworten zu lassen anstelle ebenfalls einen Broadcast zu senden (haben unsere Kollegen in den Staaten so gemacht). Sehen sich beide Geräte nicht auf direktem Wege schlägt so die Erkennung fehl.
Hat jemand da andere Erfahrungen gemacht, kann man vielleicht in /proc oder /sys etwas einstellen?
Selbst wenn man das könnte, wäre es nicht sonderlich portabel, oder?
Tschau, andre
On Sunday 30 August 2009, André Schulze wrote:
Ein schöner Implementierungsfehler ist in diesem Zusammenhang das Gerät mittels eines normalen Datagramms an die Absenderadresse antworten zu lassen anstelle ebenfalls einen Broadcast zu senden (haben unsere Kollegen in den Staaten so gemacht). Sehen sich beide Geräte nicht auf direktem Wege schlägt so die Erkennung fehl.
Das verstehe ich jetzt nicht. Unter welchen Umständen kommt ein Link-Broadcast durch, aber ein Unicast nicht?
Selber Switch: beides kommt durch.
Bridge: beides kommt durch.
Router (mit oder ohne NAT): nur Unicast kommt durch, also wäre der Broadcast nie beantwortet worden. Protokolle über Routergrenzen hinweg sollten niemals Broadcast einsetzen.
Alles andere ist ein Konfigurationsproblem im Netzwerk.
Sämtliche mir bekannte Specs, die Broadcast zur Discovery benutzen nutzen Unicast oder Multicast für die Antworten und normale Kommunikation.
Konrad
Konrad Rosenbaum konrad@silmor.de (So 30 Aug 2009 18:35:26 CEST):
Sämtliche mir bekannte Specs, die Broadcast zur Discovery benutzen nutzen Unicast oder Multicast für die Antworten und normale Kommunikation.
Bei DHCP ist der REQUEST auch ein Brotkasten, meines Wissens.
DHCP DISCOVER Broadcast OFFER Unicast REQUEST Broadcast ACK/NAK Unicast
Am Sun den 30 Aug 2009 um 06:35:26PM +0200 schrieb Konrad Rosenbaum:
On Sunday 30 August 2009, André Schulze wrote:
Ein schöner Implementierungsfehler ist in diesem Zusammenhang das Gerät mittels eines normalen Datagramms an die Absenderadresse antworten zu lassen anstelle ebenfalls einen Broadcast zu senden (haben unsere Kollegen in den Staaten so gemacht). Sehen sich beide Geräte nicht auf direktem Wege schlägt so die Erkennung fehl.
Das verstehe ich jetzt nicht. Unter welchen Umständen kommt ein Link-Broadcast durch, aber ein Unicast nicht?
...
Alles andere ist ein Konfigurationsproblem im Netzwerk.
Richtig. Hier handelt es sich um ein real life Problem ;-) Das Gerät hat eine verstellbare IP, aber kein physisches Nutzerinterface. Jetzt stellst du das Teil physisch in ein fremdes Netz (Turnschuhdatentransport sozusagen) - nun hast du erst mal ein Konfigurationsproblem im Netzwerk. Damit du jetzt dem Ding seine neue IP verklickern kannst, bleiben dir nur noch Broadcasts übrig.
Tschau, andre
On Mon, August 31, 2009 09:23, André Schulze wrote:
Am Sun den 30 Aug 2009 um 06:35:26PM +0200 schrieb Konrad Rosenbaum:
Alles andere ist ein Konfigurationsproblem im Netzwerk.
Richtig. Hier handelt es sich um ein real life Problem ;-) Das Gerät hat eine verstellbare IP, aber kein physisches Nutzerinterface. Jetzt stellst du das Teil physisch in ein fremdes Netz (Turnschuhdatentransport sozusagen) - nun hast du erst mal ein Konfigurationsproblem im Netzwerk. Damit du jetzt dem Ding seine neue IP verklickern kannst, bleiben dir nur noch Broadcasts übrig.
Ahh, ich verstehe. Die Loesung dafuer ist nicht Broadcast Total, sondern DHCP. Heutzutage wuerde ich sogar auf IPv6 bestehen, da loest sich das Problem via Link-Local (fe80::*) und Router-Advertisements von selbst.
Konrad
Hallo Marcus,
auch wenn ich selbst keine zielführende Antwort parat habe, scheint ja Deine Frage recht aktuell zu sein:
http://www.mail-archive.com/ecos-discuss@ecos.sourceware.org/msg10377.html
Vielleicht hilft Dir das in irgend einer Weise weiter, falls Du's noch nicht gefunden hattest. (Scheint ja relativ neu zu sein.)
Das ,,Broadcast''-Paket kommt unter Linux im besten Falle auf einem der verfügbaren Interface heraus. Hat man keine Default-Route oder womöglich 255.255.255.255 nicht direkt in der Routing-Tabelle eingetragen, wird das Paket gar nicht versendet und man bekommt ,,Network unreachable''.
Auch mit mehreren Routen in der Routing-Tablette wird nicht das passieren, was Du willst, denn ich denke, der Netzwerk-Stack dupliziert keine Pakete (was er ja auch im von Dir „unterstellten“ Verhalten hätte tun müssen.). Du hast dann eher sowas wie Lastverteilung.
Wahrscheinlich also bleibt es bei händischem Senden je Interface.
lug-dd@mailman.schlittermann.de
-
André Schulze -
Heiko Schlittermann -
Konrad Rosenbaum -
Marcus Obst