Default-Route als MAC-Adresse angeben
Ingo van Lil
laut Spezifikation für ein Linux-basiertes Gerät, an dem ich zur Zeit
arbeite, soll das Default-Gateway wahlweise als IP- oder als MAC-Adresse
angegeben werden können. Ersteres ist ja der übliche Weg, aber die
einzige Lösung, die mir für den zweiten Fall einfällt, ist:
- Dummy-IP fürs Gateway ausdenken
- Statische Host-Route für diese IP eintragen
- Permanenten ARP-Eintrag für diese IP und die gewünschte MAC eintragen
- Default-Route auf diese IP setzen
Ist also alles in allem ganz schön häßlich. Gibt's dafür eine elegantere
Möglichkeit (Linux 2.4, iproute2, notfalls iptables)?
Tschau,
Ingo
Mario 'BitKoenig' Holbe
> arbeite, soll das Default-Gateway wahlweise als IP- oder als MAC-Adresse
> angegeben werden können. Ersteres ist ja der übliche Weg, aber die
> einzige Lösung, die mir für den zweiten Fall einfällt, ist:
Geraet herausfinden, dem die MAC-Adresse gehoert...
dev="$(ifconfig | awk '/ <MAC> *$/ { print $1 }')"
Route mit "dev" adden.
route add default dev "$dev"
regards
Mario
--
To err is human. To really foul things up requires a computer.
Ingo van Lil
>> arbeite, soll das Default-Gateway wahlweise als IP- oder als MAC-Adresse
>> angegeben werden können. Ersteres ist ja der übliche Weg, aber die
>> einzige Lösung, die mir für den zweiten Fall einfällt, ist:
>
> Geraet herausfinden, dem die MAC-Adresse gehoert...
> dev="$(ifconfig | awk '/ <MAC> *$/ { print $1 }')"
> Route mit "dev" adden.
> route add default dev "$dev"
Tut mir leid, falls ich mich mißverständlich ausgedrückt habe: Es geht
nicht um ein lokales Interface (davon hat mein Gerät üblicherweise nur
eins), es geht um den Router, der die Verbindung zur Außenwelt
bereitstellt (eben das Default-Gateway). Von diesem ist unter Umständen
nur die MAC-Adresse bekannt, nicht aber die IP. Und an eben diese MAC
sollen eben alle Pakete weitergeleitet, die nicht ins eigene Subnetz
gehören. Ich weiß nur nicht, wie ich das meinem Linux-Kernel am
gescheitesten erkläre.
Tschau,
Ingo
Mario 'BitKoenig' Holbe
> bereitstellt (eben das Default-Gateway). Von diesem ist unter Umständen
> nur die MAC-Adresse bekannt, nicht aber die IP. Und an eben diese MAC
Oerks. Ja, dann faellt mir auch nur die Variante mit dummy-IP und
statischem ARP-Eintrag ein.
regards
Mario
--
Ho ho ho! I am Santa Claus of Borg. Nice assimilation all together!
Paul Muster
Ich habe gerade guessnet entdeckt, das kann auch auf MAC-Adressen
testen. Vielleicht kannst du damit deine Aufgabenstellung eleganter lösen.
mfG Paul
Jakob Hirsch
> Ich weiss nicht, ob Linux überhaupt rarp spricht. Auf jeden Fall wird
> das, was Du beschreibst (lokalen ARP-Table manipulieren) so nicht
> klappen. Desweiteren fehlen Netzmasken. Man könnte es mit einer
> Point-to-Point-Route versuchen.
Warum sollte das nicht funktionieren? Mit RARP das nichts zu tun, daß
ist ein eigenes Protokoll.
Netmask ist kein Problem, du kannst eth0 mit /32 konfigurieren, eine
hostroute auf dev eth0 setzen und die IP dieser hostroute als default
route einrichten. Wird ja von rootserver-hostern auch so gemacht.
> Wie auch immer: Das ganze ist _äußerst_ schräg.
Allerdings...
Ingo van Lil
>> [...]. Ich weiß nur nicht, wie ich das meinem Linux-Kernel am
>> gescheitesten erkläre.
>
> Garnicht. Die Idee ist schon verdreht.
Erklär das den Helden, die IPMI spezifiziert haben (sprich: Intel).
> Ich weiss nicht, ob Linux überhaupt rarp spricht.
Was bitte hat RARP damit zu tun?
> Auf jeden Fall wird das, was Du beschreibst (lokalen ARP-Table
> manipulieren) so nicht klappen.
Aha. Könntest Du diese Aussage bitte begründen?
> Desweiteren fehlen Netzmasken.
Nö. Eigene IP und Netzmaske des lokalen Subnetzes sind natürlich
bekannt. Der einzige Unterschied zum Standard-Fall ist, daß vom Default-
Gateway eben nicht die IP, sondern nur die MAC sowie das Interface, über
welches es zu erreichen ist, gegeben sind.
> Wie auch immer: Das ganze ist _äußerst_ schräg.
Aus Sicht eines vollwertigen Betriebssystems mit ARP-Implementierung,
Routing-Tabelle etc. mag das "schräg" sein; deswegen hab ich ja jetzt
die Probleme, das nachzubilden. Im Embedded-Umfeld, wo man sich auf
das Allernötigste beschränken möchte, kann es aber durchaus sinnvoll
sein.
Tschau,
Ingo
--
Hobbes: How come we play war and not peace?
Calvin: Too few role models. -- Bill Watterson, Calvin and Hobbes
Bodo `Garfield' Bellut
Mittels arping eine ARP-Anfrage stellen und anschließend im lokalen
ARP-Cache nachsehen?
cu, Bodo
--
Bodo Bellut bo...@bellut.net | USE PGP! +-----------+
Stangefolstr. 17 Fax/Mobile: just ask | (key via server |\ O---m /|
44141 Dortmund Fon: +49-700-77-BELLUT | or on request) |/---------\|
PGP: 768/FA18A639 AE 5A 47 40 5A A0 D6 15 8E 54 44 AA 8D DD 6E BD+-----------+
Ingo van Lil
> Mittels arping eine ARP-Anfrage stellen und anschließend im lokalen
> ARP-Cache nachsehen?
Damit kann ich zu einer IP die passende MAC herausfinden, das kann Linux
aber ebensogut selbst machen. Ich weiß die MAC aber schon und bin an der
IP eigentlich herzlich wenig interessiert. Ich will lediglich alle
Pakete, die ich nicht direkt zustellen kann, an eben diese MAC
weiterreichen.
Aber gut, es schaut wohl ganz so aus, als ob es keine einfachere Lösung
als die von mir vorgeschlagenen gibt. Jetzt muß ich also nur noch eine
IP finden, die ich als Dummy-Adresse fürs Gateway eintragen kann und die
garantiert nirgends in der Praxis auftaucht. Aber ich denke mal, mit
1.1.1.1 o.ä. bin ich da auf der sicheren Seite.
Mario 'BitKoenig' Holbe
> garantiert nirgends in der Praxis auftaucht. Aber ich denke mal, mit
> 1.1.1.1 o.ä. bin ich da auf der sicheren Seite.
Ha, wusste ich doch, dass das noch kommt :)
Spricht was gegen private oder zeroconf-IPs?
regards
Mario
--
Whenever you design a better fool-proof software,
the genetic pool will always design a better fool.
Bodo `Garfield' Bellut
>
>> Mittels arping eine ARP-Anfrage stellen und anschließend im lokalen
>> ARP-Cache nachsehen?
>
>Damit kann ich zu einer IP die passende MAC herausfinden, das kann Linux
Nein, arping schickt ARP-Pakete an MAC-Adressen, keine IP-Pakete. Sobald
die Antwort vom Router da ist, kennt Linux die IP und diese kann für die
Route benutzt werden.
>aber ebensogut selbst machen. Ich weiß die MAC aber schon und bin an der
>IP eigentlich herzlich wenig interessiert. Ich will lediglich alle
>Pakete, die ich nicht direkt zustellen kann, an eben diese MAC
>weiterreichen.
So geht das aber nunmal nicht. Wenn Du aber auf obige Weise (oder jede
andere) die IP des Gateways gefunden hast, kannst Du die benutzen.
>Aber gut, es schaut wohl ganz so aus, als ob es keine einfachere Lösung
>als die von mir vorgeschlagenen gibt. Jetzt muß ich also nur noch eine
Ich empfinde meine Lösung als einfacher, aber das muss ja jeder selber
wissen.
>IP finden, die ich als Dummy-Adresse fürs Gateway eintragen kann und die
>garantiert nirgends in der Praxis auftaucht. Aber ich denke mal, mit
>1.1.1.1 o.ä. bin ich da auf der sicheren Seite.
1.0.0.0/8 ist für die Zukunft reserviert, Du kannst keinesfalls sicher sein,
daß das nicht irgendwann in Benutzung ist. Wenn das in alle möglichen Netzen
funktionieren soll, dann kannst Du überhaupt keine IP einfach so verwenden,
es ist immer möglich, daß die in dem Netz in Benutzung ist.
Da wäre 192.0.0.192 noch die beste Wahl, die IP kann eh nicht mehr für
sinnvolle Zwecke verwendet werden.
Es gibt schon genug defekte Software/Hardware, die fremde oder reservierte
IPs benutzt, bitte produziere nicht noch eine.
Ingo van Lil
>>> Mittels arping eine ARP-Anfrage stellen und anschließend im lokalen
>>> ARP-Cache nachsehen?
>>
>>Damit kann ich zu einer IP die passende MAC herausfinden, das kann Linux
>
> Nein, arping schickt ARP-Pakete an MAC-Adressen, keine IP-Pakete.
ARP-Pakete an MAC-Adressen zu schicken klingt für meine Ohren ein
wenig unsinnig.
> Sobald die Antwort vom Router da ist, kennt Linux die IP und diese
> kann für die Route benutzt werden.
OK, es sind offenbar zwei verschiedene Programme unter dem Namen
"arping" im Umlauf. Meins stammt aus den "iputils" und kann
ausschließlich ARP-Queries nach einer gegebenen IP stellen. Genau dazu
ist ARP ja auch eigentlich da.
Ich hab mir jetzt mal gerade das arping von
http://www.habets.pp.se/synscan/programs.php angeschaut, meinst Du das?
Das schickt, wenn als Ziel eine MAC angegeben ist, lediglich ganz
normale ICMP-Pings an die Broadcast-MAC raus. Sehr fraglich, wieviele
Systeme auf so etwas überhaupt reagieren. Mein WLAN-Router scheint sich
z.B. nicht darum zu scheren.
> Da wäre 192.0.0.192 noch die beste Wahl, die IP kann eh nicht mehr für
> sinnvolle Zwecke verwendet werden.
OK, die Adresse war mir nicht bekannt. Ist durchaus eine Option.
> Es gibt schon genug defekte Software/Hardware, die fremde oder reservierte
> IPs benutzt, bitte produziere nicht noch eine.
Das "Benutzen" der fremden IP beschränkt sich in dem Fall
glücklicherweise darauf, daß genau diese eine Adresse für das Gerät
unereichbar bleibt. Die Dummy-Adresse, welche auch immer das sein mag,
verläßt unter keinen Umständen mein System.
Ingo van Lil
>> Es gibt schon genug defekte Software/Hardware, die fremde oder reservierte
>> IPs benutzt, bitte produziere nicht noch eine.
>
> Das "Benutzen" der fremden IP beschränkt sich in dem Fall
> glücklicherweise darauf, daß genau diese eine Adresse für das Gerät
> unereichbar bleibt. Die Dummy-Adresse, welche auch immer das sein mag,
> verläßt unter keinen Umständen mein System.
Je mehr ich darüber nachdenke: Ich muß lediglich sicherstellen, daß die
verwendete Dummy-Adresse _nicht_ in Subnetz des Gerätes liegt. Für den
furchtbar unwahrscheinlichen Fall, daß dann tatsächlich mal jemand von
eben dieser Adresse auf das Gerät zugreifen will, wird mein System der
fest eingetragenen Host-Route für eben diese IP folgen, den statischen
ARP-Eintrag anschauen und seine Antworten ans Gateway schicken -- und
genau da gehören sie auch hin. Das Gerät würde sich also unter allen
Umständen absolut standardkonform verhalten. :-)
Juergen Ilse
Ingo van Lil <ing...@gmx.de> wrote:
> Aber gut, es schaut wohl ganz so aus, als ob es keine einfachere Lösung
> als die von mir vorgeschlagenen gibt. Jetzt muß ich also nur noch eine
> IP finden, die ich als Dummy-Adresse fürs Gateway eintragen kann und die
> garantiert nirgends in der Praxis auftaucht. Aber ich denke mal, mit
> 1.1.1.1 o.ä. bin ich da auf der sicheren Seite.
Wenn es keine aus einem lokalen Subnetz ist, bekommst du damit das
naechste Problem, und irgendwie glaube ich nicht so recht, dass 1.1.1.1
eine Adresse aus deinem lokalen Subnetz ist ...
Ausserdem solltest du keine "Innominate mGuard" in Defaultkonfiguration
im Netz haben, wenn du die 1.1.1.1 fuer irgend etwas missbrauchen willst.
Wenn dein Gateway etwas ist, was auf Broadcast-Pings antwortet (unixoide
Systeme tun das per Default, Windows-Systeme dagegen nicht) koenntest du
evt. einen Broadcast-Ping absetzen und den Arp-Cache nach der IP-Adresse
deines Gateways durchsuchen ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Ingo van Lil
> Wenn es keine aus einem lokalen Subnetz ist, bekommst du damit das
> naechste Problem, und irgendwie glaube ich nicht so recht, dass 1.1.1.1
> eine Adresse aus deinem lokalen Subnetz ist ...
Nanu, eigentlich hab ich mit Absicht eine Adresse gewählt, die
garantiert nicht im eigenen Subnetz ist. Andernfalls wären Konflikte
quasi vorprogrammiert.
> Ausserdem solltest du keine "Innominate mGuard" in Defaultkonfiguration
> im Netz haben, wenn du die 1.1.1.1 fuer irgend etwas missbrauchen willst.
Warum? Innominate mGuard sagt mir nichts, aber was kümmern mich andere
Hosts bei meinen internen Routing-Entscheidungen?
> Wenn dein Gateway etwas ist, was auf Broadcast-Pings antwortet (unixoide
> Systeme tun das per Default, Windows-Systeme dagegen nicht) koenntest du
> evt. einen Broadcast-Ping absetzen und den Arp-Cache nach der IP-Adresse
> deines Gateways durchsuchen ...
Ich weiß aber nichts über das Gateway, oder darüber, was der Kunde mit
dem Gerät vorhat. Ich will mich also auf möglichst wenige unsichere
Vermutungen verlassen, mein Setup soll einfach unter allen Umständen
funktionieren.
Also gut, ganz konkretes Beispiel: Mein Gerät hat die 192.168.1.215/24,
vom Gateway ist nur bekannt, daß es über eth0 erreichbar ist und die MAC
00:de:ad:be:ef:42 hat. Was spricht also gegen folgendes Setup?
ifconfig eth0 192.168.1.215 netmask 255.255.255.0
DUMMY=1.1.1.1
route add -host $DUMMY eth0
arp -s $DUMMY 00:de:ad:be:ef:42
route add default gw $DUMMY
Bitte nur objektive Gründe; "Das ist krank!" laß ich nicht gelten, das
weiß ich selbst. ;-)
Der einzige Nachteil, der mir einfällt: ICMP-Nachrichten vom Gateway
(z.B. Redirects) werden nicht als solche erkannt. Damit muß man aber
zwangsläufig leben, wenn man dessen IP verschweigt.
Tschau,
Ingo
Patrick Schaaf
>[...] ich denke mal, mit 1.1.1.1 o.ä. bin ich da auf der sicheren Seite.
Geht nicht 127.0.0.1^H2? Oder 255.255.255.255? :)
Gruss
Patrick
Ingo van Lil
>>[...] ich denke mal, mit 1.1.1.1 o.ä. bin ich da auf der sicheren Seite.
>
> Geht nicht 127.0.0.1^H2? Oder 255.255.255.255? :)
127.0.0.2 nicht, das wird anscheinend intern noch vor der Routingtabelle
abgefangen. 255.255.255.254 hatte bei meinen gestrigen Experimenten der
ARP-Cache im Kernel 2.6 nicht akzeptiert (EINVAL beim Setzen des
statischen Eintrags), 2.4 scheint tatsächlich kein Problem damit zu
haben.
Tschau,
Ingo
Bodo `Garfield' Bellut
>Bodo `Garfield' Bellut schrieb:
[snip]
>> Sobald die Antwort vom Router da ist, kennt Linux die IP und diese
>> kann für die Route benutzt werden.
>
>OK, es sind offenbar zwei verschiedene Programme unter dem Namen
>"arping" im Umlauf. Meins stammt aus den "iputils" und kann
>ausschließlich ARP-Queries nach einer gegebenen IP stellen. Genau dazu
>ist ARP ja auch eigentlich da.
>
>Ich hab mir jetzt mal gerade das arping von
>http://www.habets.pp.se/synscan/programs.php angeschaut, meinst Du das?
>Das schickt, wenn als Ziel eine MAC angegeben ist, lediglich ganz
>normale ICMP-Pings an die Broadcast-MAC raus. Sehr fraglich, wieviele
>Systeme auf so etwas überhaupt reagieren. Mein WLAN-Router scheint sich
>z.B. nicht darum zu scheren.
Nein, das meine ich nicht, das habe ich verwexelt. Ich hatte da mal ein
Tool, daß im Prinzip das, was ping auf IP-Ebene macht, auf Ethernet-Ebene
machte. Ich war der Meinung, es wäre arping gewesen, ist's aber nicht. Ich
komme aber partout nicht mehr auf den Namen und kann's auch hier nicht mehr
finden.
Ich nehme an, IRDP (RFC 1256) kommt nicht in Frage?
Ingo van Lil
>> Warum sollte das nicht funktionieren? [...]
>
> Der Hinweg funktioniert. Der Rückweg im Regelfall aber nicht.
Was verstehst Du unter Hin- und Rückweg? Siehst Du ein Problem beim
Empfangen von Paketen (zu meinem Device hin) oder beim Verschicken?
> Wenn ich im arp table eine entsprechende Zuordnung installiere und die
> Default-Route entsprechend setze habe ich mindestens das Problem, dass
> diese IP-Adresse bereits vergeben sein kann.
Na und?
> Nun route ich den Traffic
> raus und die Antowrt kommt zurück. Der Router hat aber lustigerweise
> eine IP auf dem entsprechenden Interface, die nicht zu meiner Absender-
> Adresse passt, also verwirft er das Paket.
Ich vermag Dir leider immer noch nicht zu folgen. Welches Paket sieht
für den Router in irgendeiner Weise falsch aus? Jedes von meinem Gerät
verschickte Paket enthält selbstverständlich dessen gültige, vom Admin
eingestellte IP als Absenderadresse. Warum sollte der Router das nicht
akzeptieren?
Juergen Ilse
Ingo van Lil <ing...@gmx.de> wrote:
> Juergen Ilse schrieb:
>> Ausserdem solltest du keine "Innominate mGuard" in Defaultkonfiguration
>> im Netz haben, wenn du die 1.1.1.1 fuer irgend etwas missbrauchen willst.
> Warum? Innominate mGuard sagt mir nichts, aber was kümmern mich andere
> Hosts bei meinen internen Routing-Entscheidungen?
Innominate mGuard ist eine Firewall, die als Default-Einstellung als
"filternde Bridge" konfiguriert ist und sich selbst unter der IP-Adresse
1.1.1.1 angesprochen fuehlt ... Ich bin mir nicht so ganz sicher, ob das
im Zusammenhang mit den von dir angedachten Tricksereien nicht zu dem
einen oder anderen eher nicht erwuenschten Effekt fuehren wird ...
> Ich weiß aber nichts über das Gateway, oder darüber, was der Kunde mit
> dem Gerät vorhat. Ich will mich also auf möglichst wenige unsichere
> Vermutungen verlassen, mein Setup soll einfach unter allen Umständen
> funktionieren.
Ich halte die ganze Idee fuer voellig krank (und wenn irgendwelche Leute
bei Intel so etwas fuer eine furchtbar gute Idee halten, aendert das an
meiner Meinung zu solch einem Schmuh nicht das geringste ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Ingo van Lil
> Innominate mGuard ist eine Firewall, die als Default-Einstellung als
> "filternde Bridge" konfiguriert ist und sich selbst unter der IP-Adresse
> 1.1.1.1 angesprochen fuehlt ... Ich bin mir nicht so ganz sicher, ob das
> im Zusammenhang mit den von dir angedachten Tricksereien nicht zu dem
> einen oder anderen eher nicht erwuenschten Effekt fuehren wird ...
Wieso sollte es? Mein Gerät wird die Adresse weder ansprechen noch sich
in irgendeiner Weise selbst für diese Adresse verantwortlich fühlen. Was
irgendwelche kaputtkonfigurierten Stücke Netztechnik machen, ist mir
egal, solange ich mich standardkonform verhalte.
> Ich halte die ganze Idee fuer voellig krank (und wenn irgendwelche Leute
> bei Intel so etwas fuer eine furchtbar gute Idee halten, aendert das an
> meiner Meinung zu solch einem Schmuh nicht das geringste ...).
OK, daß schon die Idee hier von allen Seiten verachtet wird, hab ich
mittlerweile verstanden. Nur hab ich bisher noch nicht eine objektive
Begründung dafür gelesen. Wozu muß ein Gerät, das einfach nur IP-Pakete
über ein Gateway verschicken möchte, dessen IP wissen? Die IP wird IMHO
für genau zwei Dinge verwendet: Erstens, um zu entscheiden, über welches
Interface das Gateway erreichbar ist und zweitens, um mittels ARP die
passende MAC zu erfragen. Wenn diese zwei Informationen fest vorgegeben
sind, ist die IP-Adresse für alles weitere völlig belanglos.
Jakob Hirsch
>> Warum sollte das nicht funktionieren? [...]
> Der Hinweg funktioniert. Der Rückweg im Regelfall aber nicht.
Klar, natürlich muß auf dem Router das auch entsprechend gemacht werden,
incl. routing etc., was das Ganze noch kranker macht, weil man dann
genausogut sauberes IP aufsetzen könnten.
Florian Laws
Was hat der Router mit der Implementierung auf einem Host zu schaffen?
Grüße,
Florian
Jakob Hirsch
> Was hat der Router mit der Implementierung auf einem Host zu schaffen?
Der Router muß wissen, welche Adresse der host hat.
Andererseits wäre natürlich das tollste Killer-Feature nach Erfindung
der auto-learning bridge: auto-learning router.
Juergen P. Meier
> Bodo `Garfield' Bellut schrieb:
>
>> Mittels arping eine ARP-Anfrage stellen und anschließend im lokalen
>> ARP-Cache nachsehen?
>
> Damit kann ich zu einer IP die passende MAC herausfinden, das kann Linux
> aber ebensogut selbst machen. Ich weiß die MAC aber schon und bin an der
> IP eigentlich herzlich wenig interessiert. Ich will lediglich alle
> Pakete, die ich nicht direkt zustellen kann, an eben diese MAC
> weiterreichen.
> Aber gut, es schaut wohl ganz so aus, als ob es keine einfachere Lösung
> als die von mir vorgeschlagenen gibt. Jetzt muß ich also nur noch eine
> IP finden, die ich als Dummy-Adresse fürs Gateway eintragen kann und die
> garantiert nirgends in der Praxis auftaucht. Aber ich denke mal, mit
> 1.1.1.1 o.ä. bin ich da auf der sicheren Seite.
arping != arping.
Es gibt mind. 3 total verschiedene Implementierungen mit diesem
Namen. WEnn du eine Linux-Distribution hast, die das "richtige" arping
verwendet, dann geht das sehr wohl.
Ansonsten nimmt man das bootp Protokoll fuer diesen Zweck, sofern
vom Router unterstuetzt.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Ingo van Lil
>> Was hat der Router mit der Implementierung auf einem Host zu schaffen?
>
> Der Router muß wissen, welche Adresse der host hat.
Wozu denn bitte das? Der Router macht ganz normal seinen Job: Er bekommt
ein Paket, das für irgendeinen beliebigen Host in einem seiner Subnetze
bestimmt ist, erfragt die MAC des Zielhosts und stellt das Paket zu. Das
ist sein Job, das macht jeder Router mehr oder weniger so. Wo liegt das
Problem?
Tschau,
Ingo
Florian Laws
> Quoting Florian Laws:
>
>> Was hat der Router mit der Implementierung auf einem Host zu schaffen?
>
> Der Router muß wissen, welche Adresse der host hat.
Und die erfährt er ganz normal per ARP. Wo ist das Problem?
Grüße,
Florian
Patrick Schaaf
Welche Quell-IP wird dieses Paket haben?
Antworten werden nie erwartet?
Kennst Du die heutzutage nicht unuebliche Router-Funktion, empfangene
Pakete sofort zu verwerfen, wenn deren Quell-IP nicht per Router-lokaler
Routingtabelle auf dem Empfangsinterface auch wieder rueckwaerts
erreicht werden soll? Cisco-Feature 'ip verify unicast reverse-path',
oder Linux /proc/sys/net/ipv4/conf/*/rp_filter, falls Du googeln willst.
Gruss
Patrick
Ingo van Lil
>>Wozu denn bitte das? Der Router macht ganz normal seinen Job: Er bekommt
>>ein Paket, das für irgendeinen beliebigen Host in einem seiner Subnetze
>>bestimmt ist, erfragt die MAC des Zielhosts und stellt das Paket zu. Das
>>ist sein Job, das macht jeder Router mehr oder weniger so. Wo liegt das
>>Problem?
>
> Welche Quell-IP wird dieses Paket haben?
Pakete von meinem Gerät haben logischerweise die vom Admin eingestellte
IP des Geräts.
> Antworten werden nie erwartet?
Doch, selbstverständlich. Aber auf den Empfang von Paketen haben meine
Einstellungen in Routing-Tabelle und ARP-Cache nicht den geringsten
Einfluß.
> Kennst Du die heutzutage nicht unuebliche Router-Funktion, empfangene
> Pakete sofort zu verwerfen, wenn deren Quell-IP nicht per Router-lokaler
> Routingtabelle auf dem Empfangsinterface auch wieder rueckwaerts
> erreicht werden soll? Cisco-Feature 'ip verify unicast reverse-path',
> oder Linux /proc/sys/net/ipv4/conf/*/rp_filter, falls Du googeln willst.
Wer redet denn davon, die Absender-IP zu fälschen? Ich brauch lediglich
System-intern eine IP-Adresse als Schlüssel für die ARP- und Routing-
Tabellen. Das herausgeschickte Paket dürfte sich in keinster Weise von
einem "normal" erzeugten unterscheiden: Eigene MAC als Quell-MAC, eigene
IP als Quell-IP, MAC des Gateways (aus permanentem ARP-Eintrag) als
Ziel-MAC, IP des endgültigen Empfängers als Ziel-IP.
Tschau,
Ingo
Patrick Schaaf
>Patrick Schaaf schrieb:
>>>Wozu denn bitte das? Der Router macht ganz normal seinen Job: Er bekommt
>>>ein Paket, das für irgendeinen beliebigen Host in einem seiner Subnetze
>>>bestimmt ist, erfragt die MAC des Zielhosts und stellt das Paket zu. Das
>>>ist sein Job, das macht jeder Router mehr oder weniger so. Wo liegt das
>>>Problem?
>>
>> Welche Quell-IP wird dieses Paket haben?
>Pakete von meinem Gerät haben logischerweise die vom Admin eingestellte
>IP des Geräts.
Ok. Der Admin stellt also eine IP-Adresse ein, und die MAC des Gateways,
und nicht nur die MAC des Gateways. Da koennte er genauso gut statt der
MAC des Gateways auch zum Einstellen der richtigen Gateway-IP+Maske
genoetigt werden.
Ich schliesse mich hiermit der allgemeinen Ansicht an, dass das Mist ist.
Davon abgesehen hast Du natuerlich Recht, dass es funktionieren wird.
Viel Spass damit.
Gruss
Patrick
Jakob Hirsch
>>> Was hat der Router mit der Implementierung auf einem Host zu schaffen?
>> Der Router muß wissen, welche Adresse der host hat.
> Wozu denn bitte das? Der Router macht ganz normal seinen Job: Er bekommt
> ein Paket, das für irgendeinen beliebigen Host in einem seiner Subnetze
Wenn der Host in "einem seiner Subnetze" ist, ist ja alles wunderbar.
Bei dem beschriebenen Setup gibt es aber offensichtlich kein normales
subnetz, der Router muß nichtmal eine IP-Adresse auf dem Interface
haben, und wenn er eine hat, muß diese nicht zwangsläufig im selben
subnetz sein und das subnetz könnte einfach /32 sein oder sonstwas. Es
wurde einfach keine Aussage darüber getroffen. Dran denken sollte man
aber schon, wenn man sowas macht.
Jakob Hirsch
>>> Was hat der Router mit der Implementierung auf einem Host zu schaffen?
>> Der Router muß wissen, welche Adresse der host hat.
> Und die erfährt er ganz normal per ARP. Wo ist das Problem?
ARP macht IP-Adresse -> MAC-Adresse, nicht umgekehrt.
Florian Laws
Mehr braucht der Router ja auch nicht.
Der Host ist es, der hier die ungewöhnlichen Anforderungen hat,
deswegen verstehe ich nicht, was sich alle den Kopf über den
Router zerbrechen.
Grüße,
Florian
Ingo van Lil
>> Wozu denn bitte das? Der Router macht ganz normal seinen Job: Er bekommt
>> ein Paket, das für irgendeinen beliebigen Host in einem seiner Subnetze
>
> Wenn der Host in "einem seiner Subnetze" ist, ist ja alles wunderbar.
Na prima. Welche IP das Gerät bekommt, liegt in der Hand des Admins.
Wenn der da irgendwelchen Blödsinn einstellt, kann ich auch nichts dran
ändern.
> Bei dem beschriebenen Setup gibt es aber offensichtlich kein normales
> subnetz, der Router muß nichtmal eine IP-Adresse auf dem Interface
> haben, und wenn er eine hat, muß diese nicht zwangsläufig im selben
> subnetz sein und das subnetz könnte einfach /32 sein oder sonstwas.
Der Router sollte natürlich seiner Aufgabe entsprechend konfiguriert
sein. Auch das liegt im Verantwortungsbereich des Admins.
Der IPMI-Standard verlangt nun aber von meinem Gerät, daß das Default-
Gateway wahlweise statt anhand seiner IP auch direkt als MAC-Adresse
eingestellt werden können soll -- mir ist nicht klar, warum jemand diese
Möglichkeit in Anspruch nehmen wollen sollte, aber ich muß sie
zumindest anbieten, wenn ich mich standardkonform verhalten will. Und da
Linux dieses Feature nicht direkt zu unterstützen scheint und ich wenig
Lust verspüre, es umständlich nachzurüsten, stellt sich mir nun die
Frage, ob ich mir in irgendeiner Weise Probleme einhandeln könnte, wenn
ich die Funktionalität durch eine "ausgedachte" IP-Adresse, eine
Host-Route und einen permanenten ARP-Eintrag nachbildete.
Tschau,
Ingo
Mario 'BitKoenig' Holbe
> ich die Funktionalität durch eine "ausgedachte" IP-Adresse, eine
> Host-Route und einen permanenten ARP-Eintrag nachbildete.
Also ich kann Deiner Argumentation (insbesondere der, dass eine
beliebige routbare IP besser ist als eine private) absolut folgen und
sehe nicht, wo Du Dir da Probleme einhandeln solltest.
regards
Mario
--
The secret that the NSA could read the Iranian secrets was more
important than any specific Iranian secrets that the NSA could
read. -- Bruce Schneier
Florian Laws
>
> Der IPMI-Standard verlangt nun aber von meinem Gerät, daß das Default-
> Gateway wahlweise statt anhand seiner IP auch direkt als MAC-Adresse
> eingestellt werden können soll
Wer hat da die Wahl, der Benutzer oder der Implementierer?
Grüße,
Florian
Ingo van Lil
>> Der IPMI-Standard verlangt nun aber von meinem Gerät, daß das Default-
>> Gateway wahlweise statt anhand seiner IP auch direkt als MAC-Adresse
>> eingestellt werden können soll
>
> Wer hat da die Wahl, der Benutzer oder der Implementierer?
Zu dem Thema schweigt sich der Standard leider aus. Es werden einfach
Kommandos definiert, um IP und MAC des Gateways zu setzen. Welche davon
für den Betrieb zwingend vorgegeben werden müssen und wie sich das Gerät
verhalten soll, wenn eine der Angaben fehlt, ist dummerweise nicht
spezifiziert. Deswegen habe ich mich entschieden, das Dokument möglichst
großzügig zu interpretieren und mein System so zu gestalten, daß es
immer funktioniert, wenn mindestens eine der beiden Adressen eingestellt
ist.
Tschau,
Ingo
Mario 'BitKoenig' Holbe
> großzügig zu interpretieren und mein System so zu gestalten, daß es
> immer funktioniert, wenn mindestens eine der beiden Adressen eingestellt
Hihi, das ist sehr lobenswert. Auch wenn andere Hersteller unter einer
"grosszuegigen Interpretation" von Standards i.d.R. genau das andere
Extrem verstehen :)
regards
Mario
--
() Ascii Ribbon Campaign
/\ Support plain text e-mail
Ingo van Lil
> Es gibt mind. 3 total verschiedene Implementierungen mit diesem
> Namen. WEnn du eine Linux-Distribution hast, die das "richtige" arping
> verwendet, dann geht das sehr wohl.
Auch, wenn meine ursprüngliche Frage mittlerweile ausreichend
durchgekaut sein dürfte: Wo finde ich denn dieses "richtige" arping?
Gentoo Linux liefert zwei Versionen mit: Eins aus dem iputils-Paket
(ftp://ftp.inr.ac.ru/ip-routing) und eins von
http://www.habets.pp.se/synscan/programs.php?prog=ARPing.
Ersteres arbeitet ausschließlich auf IP-Adressen und benutzt ARP-
Requests, um den dazugehörigen Hosts ein "Lebenszeichen" zu entlocken,
zweiteres kann alternativ ICMP-Pings an eine gewünschte MAC verschicken
(als Ziel-IP wird in dem Fall 255.255.255.255 eingesetzt). Mir ist aber
keine Möglichkeit bekannt, etwas Ähnliches rein "auf MAC-Ebene" zu
erreichen oder zuverlässig "die" IP (wer sagt überhaupt, daß es nur eine
gibt?) zu einer MAC herauszufinden.
> Ansonsten nimmt man das bootp Protokoll fuer diesen Zweck, sofern
> vom Router unterstuetzt.
Tja, KO-Kriterium. Beim Router kann ich genau eine einzige Funktionalität
voraussetzen: Er routet. Das heißt, er leitet Pakete mit lokaler Quell-IP
und fremder Ziel-IP in die richtige Richtung weiter (und andersrum).
Juergen P. Meier
> Juergen P. Meier schrieb:
>
>> Es gibt mind. 3 total verschiedene Implementierungen mit diesem
>> Namen. WEnn du eine Linux-Distribution hast, die das "richtige" arping
>> verwendet, dann geht das sehr wohl.
>
> Auch, wenn meine ursprüngliche Frage mittlerweile ausreichend
> durchgekaut sein dürfte: Wo finde ich denn dieses "richtige" arping?
> Gentoo Linux liefert zwei Versionen mit: Eins aus dem iputils-Paket
> (ftp://ftp.inr.ac.ru/ip-routing) und eins von
> http://www.habets.pp.se/synscan/programs.php?prog=ARPing.
>
> Ersteres arbeitet ausschließlich auf IP-Adressen und benutzt ARP-
> Requests, um den dazugehörigen Hosts ein "Lebenszeichen" zu entlocken,
> zweiteres kann alternativ ICMP-Pings an eine gewünschte MAC verschicken
> (als Ziel-IP wird in dem Fall 255.255.255.255 eingesetzt). Mir ist aber
> keine Möglichkeit bekannt, etwas Ähnliches rein "auf MAC-Ebene" zu
> erreichen oder zuverlässig "die" IP (wer sagt überhaupt, daß es nur eine
> gibt?) zu einer MAC herauszufinden.
Letzteres ist das, was man will. Die IP 255.255.255.255 ist bei IPv4
der All-Hosts Broadcast und wird von jedem Host den das Paket erreicht
(bei MAC-Addressierung nur der Router) verarbeitet.
>> Ansonsten nimmt man das bootp Protokoll fuer diesen Zweck, sofern
>> vom Router unterstuetzt.
>
> Tja, KO-Kriterium. Beim Router kann ich genau eine einzige Funktionalität
> voraussetzen: Er routet. Das heißt, er leitet Pakete mit lokaler Quell-IP
> und fremder Ziel-IP in die richtige Richtung weiter (und andersrum).
Er muss mindestens RfC 1812 genuegen, um sich "IP router" nennen zu
duerfen. Andernfalls hat man nur ein Stueck Alteisen mit RJ45 Buchsen,
das elektrische Energie in Waerme umwandelt.
Juergen P. Meier
Naja, noch weis man nicht, welche IP man denn vorspiegeln soll, damit
der Router den Host auch versucht lokal zu erreichen. Es nuetzt
nichts, sich eine IP Auszudenken, die der Router versucht ueber eine
Route zu entfernten Netzen zu erreichen. Dann macht er fuer diese IP
kein ARP.
Ingo van Lil
> Letzteres ist das, was man will. Die IP 255.255.255.255 ist bei IPv4
> der All-Hosts Broadcast und wird von jedem Host den das Paket erreicht
> (bei MAC-Addressierung nur der Router) verarbeitet.
Der von Dir angeführte RfC 1812 sagt zu dem Thema: "The Echo server
function MAY choose not to respond to ICMP echo requests addressed to IP
broadcast or IP multicast addresses.". Pustekuchen.
Tschau,
Ingo
Ingo van Lil
>> Der Host ist es, der hier die ungewöhnlichen Anforderungen hat,
>> deswegen verstehe ich nicht, was sich alle den Kopf über den
>> Router zerbrechen.
>
> Naja, noch weis man nicht, welche IP man denn vorspiegeln soll, damit
> der Router den Host auch versucht lokal zu erreichen. Es nuetzt
> nichts, sich eine IP Auszudenken, die der Router versucht ueber eine
> Route zu entfernten Netzen zu erreichen. Dann macht er fuer diese IP
> kein ARP.
Also noch einmal: Ich kenne meine eigene IP, ich habe nicht vor,
irgendeine andere IP als Absender-Adresse einzusetzen und ich erwarte
garantiert nicht, daß Antwortpakete an eine andere als diese IP an mich
zurückgeroutet werden. Die "ausgedachte" IP dient einzig und allein als
Ziel für die Default-Route in meiner eigenen, internen Routing-Tabelle.
Tschau,
Ingo
Oliver Schad
> es geht um den Router, der die Verbindung
> zur Außenwelt bereitstellt (eben das Default-Gateway). Von diesem
> ist unter Umständen nur die MAC-Adresse bekannt, nicht aber die IP.
Wie wäre es, wenn du Multicast benutzt, um die Router zu bekommen in
dem Subnetz?
------- http://www.iana.org/assignments/multicast-addresses
|
| 224.0.0.2 All Routers on this Subnet
|
----------------------------------------------
mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.
Ingo van Lil
>> es geht um den Router, der die Verbindung
>> zur Außenwelt bereitstellt (eben das Default-Gateway). Von diesem
>> ist unter Umständen nur die MAC-Adresse bekannt, nicht aber die IP.
>
> Wie wäre es, wenn du Multicast benutzt, um die Router zu bekommen in
> dem Subnetz?
>
> ------- http://www.iana.org/assignments/multicast-addresses
>|
>| 224.0.0.2 All Routers on this Subnet
>|
> ----------------------------------------------
Auch darauf muß ein Router nicht antworten, nicht einmal auf Pings an
seine eigene IP muß er reagieren (s. RfC 1812). Ich kann die IP des
Routers nicht zuverlässig herausfinden, und ich will und muß sie auch
nicht wissen. Ich will einfach jedes Paket, das in ein fremdes Subnetz
geroutet werden soll, an die eingestellte Gateway-MAC schicken; nach
Möglichkeit ohne irgendwelche Umwege.
Tschau,
Ingo
Oliver Schad
> Ich kann die IP
> des Routers nicht zuverlässig herausfinden, und ich will und muß sie
> auch nicht wissen.
Wieso sollte man ein Netz bauen, indem es keine Informationen über den
Router auf IP-Ebene gibt, wohl aber auf Ethernet-Ebene? Das ist doch
vollkommen krank.
Ingo van Lil
>> Ich kann die IP
>> des Routers nicht zuverlässig herausfinden, und ich will und muß sie
>> auch nicht wissen.
>
> Wieso sollte man ein Netz bauen, indem es keine Informationen über den
> Router auf IP-Ebene gibt, wohl aber auf Ethernet-Ebene? Das ist doch
> vollkommen krank.
Natürlich _hat_ der Router eine IP-Adresse, das bestreite ich ja nicht.
Der Punkt ist, daß mein Device auch funktionieren soll, wenn es diese
Adresse nicht kennt. Der Standard will das so und mindestens ein Kunde
will das so, also wird das so implementiert.
Aber wenn Du unbedingt über Sinn und Zweck der Aktion philosophieren
willst: Denkbar wäre z.B., daß das Gerät sich eine Netzwerkkarte mit dem
Betriebssystem teilen muß und ausschließlich UDP-Pakete mit einem
speziellen Zielport bekommt. In dem Fall wäre die IP-Adresse des Routers
eine völlig wertlose Information, da ich kein ARP nutzen kann, um die
dazugehörige MAC zu ermitteln.
Tschau,
Ingo
Ingo van Lil
>> Ich kann die IP
>> des Routers nicht zuverlässig herausfinden, und ich will und muß sie
>> auch nicht wissen.
>
> Wieso sollte man ein Netz bauen, indem es keine Informationen über den
> Router auf IP-Ebene gibt, wohl aber auf Ethernet-Ebene? Das ist doch
> vollkommen krank.
Natürlich _hat_ der Router eine IP-Adresse, das bestreite ich ja nicht.
Der Punkt ist, daß mein Device auch funktionieren soll, wenn es diese
Adresse nicht kennt. Der IPMI-Standard will das so und mindestens ein
Ingo van Lil
>> [...]. Der IPMI-Standard will das so [...]
>
> Hast Du dazu bitte mal einen Link!?
http://www.intel.com/design/servers/ipmi/pdf/IPMIv2_0_rev1_0_E3_markup.pdf
Im Abschnitt 23.1/23.2 (Set LAN Configuration Parameters Command) sind
die Parameter Default Gateway Address (0x12) und Default Gateway MAC
Address (0x13) unabhängig voneinander aufgeführt, und weder der eine
noch der andere sind als read-only oder optional gekennzeichnet.
>> [...] und mindestens ein Kunde will das so, also wird das so
>> implementiert.
>
> Dümstest mir bekanntes Argument. Wenn der Kunde will, dass Du einen
> Handstand machst und dabei wie ein Nashorn schnauftst, machst Du das
> auch(?).
Nein, das ist nicht mein Job. Aber wenn der Kunde will, daß im
Webinterface am 1. April alle Buttons in Spiegelschrift erscheinen, er
entsprechend dafür zahlt und mein Chef mich auf das Projekt ansetzt,
dann bau ich ihm das ein.
Juergen Ilse
Ingo van Lil <ing...@gmx.de> wrote:
> http://www.intel.com/design/servers/ipmi/pdf/IPMIv2_0_rev1_0_E3_markup.pdf
>
> Im Abschnitt 23.1/23.2 (Set LAN Configuration Parameters Command) sind
> die Parameter Default Gateway Address (0x12) und Default Gateway MAC
> Address (0x13) unabhängig voneinander aufgeführt, und weder der eine
> noch der andere sind als read-only oder optional gekennzeichnet.
Wenn keiner der beiden Parameter optional ist, muessten beide spezifiziert
werden. Wo steht, dass es genuegen muss, nur die MAC-Adresse des Default-
gateways anzugeben? Wo steht, dass dann die zugehoerige IP-Adresse vom
Geraet automatisch ermittelt werden muss?
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Ingo van Lil
>> Im Abschnitt 23.1/23.2 (Set LAN Configuration Parameters Command) sind
>> die Parameter Default Gateway Address (0x12) und Default Gateway MAC
>> Address (0x13) unabhängig voneinander aufgeführt, und weder der eine
>> noch der andere sind als read-only oder optional gekennzeichnet.
>
> Wenn keiner der beiden Parameter optional ist, muessten beide spezifiziert
> werden.
"Required" oder "Optional" bezieht sich im Standard auf die
Implementierung, gibt also an, ob ein konformes Gerät den Parameter
unbedingt unterstützen muß oder nicht.
Aber vom Admin beide Parameter zu verlangen, obwohl einer vollkommen
ausreichte, wäre hanebüchener Unsinn -- immerhin wird im Normalfall nur
eine der beiden Adressen (üblicherweise die IP) gesetzt.
> Wo steht, dass es genuegen muss, nur die MAC-Adresse des Default-
> gateways anzugeben?
Nirgends. Was mit den Parametern zu machen ist, läßt der Standard im
Dunkeln. Streng genommen steht da auch nicht, daß man die eingestellte
IP-Adresse (Parameter 0x03) als Absenderadresse einsetzen soll.
> Wo steht, dass dann die zugehoerige IP-Adresse vom Geraet automatisch
> ermittelt werden muss?
Mit dem "automatisch ermitteln" habt Ihr angefangen, davon war nie die
Rede. Die IP des Gateways ist völlig belanglos, die wird ohnehin nur
verwendet, um mittels ARP die MAC zu erfragen. Die MAC ist vorgegeben,
also brauche ich die IP nicht.
Daß das Gerät intern auf Linux basiert, dessen IP-Stack an dieser Stelle
nicht besonders flexibel ist und als Ziel einer Route unbedingt eine IP
haben will, ist ein reines Implementierungsdetail. Einem Außenstehenden
ist nicht zu vermitteln, warum er eine Information eintragen soll, die
scheinbar nirgends verwendet wird und überhaupt keinen Einfluß auf das
Systemverhalten hat.
Oliver Schad
> Mit dem "automatisch ermitteln" habt Ihr angefangen, davon war nie
> die Rede. Die IP des Gateways ist völlig belanglos, die wird ohnehin
> nur verwendet, um mittels ARP die MAC zu erfragen. Die MAC ist
> vorgegeben, also brauche ich die IP nicht.
Dann tausch mal die Netzwerkkarte. Es wäre genauso sinnig, überall
IP-Adressen statt DNS-Namen zu verwenden, weil man ja nur die
IP-Adressen braucht. Ich finde die Idee einfach nur furchtbar blöd.
Patrick Schaaf
>Halleluja! Und die Sysadmins duerfen dann wieder Nachtschichten
>schieben, um die verursachten Netzwerk-Probleme zu finden.
Das wird generell in den naechsten Jahren lustig, wenn die Intel-Plaene
zu Virtualisierung von Netzwerkkarten greifen, von denen man aktuell
so lesen kann. Netzwerkkarten, die irgendwie Firewalls mit beinhalten,
teile des Traffics dabei abzwacken, und lokalen Management-Prozessoren
zustellen, selbst wenn der Rechner selbst "aus" ist. Alles toll automatisch
und die Zukunft fuer ihre Desktop-Flotte.
be afraid. be very afraid.
http://www.heise.de/newsticker/meldung/77864
Gruss
Patrick
Juergen P. Meier
> Juergen Ilse schrieb:
>
>>> Im Abschnitt 23.1/23.2 (Set LAN Configuration Parameters Command) sind
>>> die Parameter Default Gateway Address (0x12) und Default Gateway MAC
>>> Address (0x13) unabhängig voneinander aufgeführt, und weder der eine
>>> noch der andere sind als read-only oder optional gekennzeichnet.
>>
>> Wenn keiner der beiden Parameter optional ist, muessten beide spezifiziert
>> werden.
>
> "Required" oder "Optional" bezieht sich im Standard auf die
> Implementierung, gibt also an, ob ein konformes Gerät den Parameter
> unbedingt unterstützen muß oder nicht.
Ach.
> Aber vom Admin beide Parameter zu verlangen, obwohl einer vollkommen
> ausreichte, wäre hanebüchener Unsinn -- immerhin wird im Normalfall nur
Die Aussage "obwohl einer vollkommen ausreicht" ist schlicht falsch.
Bei Paketrouting ueber ein OSI-Schicht-3 Protokoll wie IP muss die IP
Adresse des routenden Gateways bekannt sein und konfiguriert werden.
Das steht vielleicht so nicht in obigem Standard, dafuer aber im IETF
Standard. Du darfst damit deinem Kunden gegenueber gerne Argumentieren.
> eine der beiden Adressen (üblicherweise die IP) gesetzt.
Falsch: Es wird zwangslaeufig IP gesetzt, es sei denn, es handelt sich
um ein unnummeriertes Punkt-zu-Punkt Interface. Das ist in deinem
Konzept aber nicht der Fall.
>> Wo steht, dass es genuegen muss, nur die MAC-Adresse des Default-
>> gateways anzugeben?
>
> Nirgends. Was mit den Parametern zu machen ist, läßt der Standard im
> Dunkeln. Streng genommen steht da auch nicht, daß man die eingestellte
> IP-Adresse (Parameter 0x03) als Absenderadresse einsetzen soll.
Dann Schreib du es halt in deiner Dokumentation vor!
>> Wo steht, dass dann die zugehoerige IP-Adresse vom Geraet automatisch
>> ermittelt werden muss?
>
> Mit dem "automatisch ermitteln" habt Ihr angefangen, davon war nie die
Ja. Und zwar aus folgendem einfachen Grund:
Es Geht normalerweise nicht Ohne!
Was du zu wollen scheinst, ist ein unnummeriertes P2P Interface ueber
ein shared medium. Wenn du das willst, dann musst du das aber auch
genau so spezifizieren und eine entsprechende Konfiguration der
Gegenseite vorgeben.
> Rede. Die IP des Gateways ist völlig belanglos, die wird ohnehin nur
> verwendet, um mittels ARP die MAC zu erfragen. Die MAC ist vorgegeben,
> also brauche ich die IP nicht.
Dann bastel deine Implementierung halt so, dass wenn eine MAC Adresse
in der Konfiguration angegeben wurde, du irgend einen Phantasiewert
fuer die IP Adresse ausdenkst, diese dem IP Stack als "route
destination" mitteilst und feste die MAC Adresse per statischem
ARP-Tabelleneintrag zuteilst.
Das hat dann nicht mehr viel mit Internet Protokoll gemaess IETF
Standards zu tun, ist aber eine praktikable und nicht selten
implementierte Loesung.
> Daß das Gerät intern auf Linux basiert, dessen IP-Stack an dieser Stelle
> nicht besonders flexibel ist und als Ziel einer Route unbedingt eine IP
Der IP Stack von Linux haelt sich so weit moeglich an geltende
Standards. Wenn du solche Hacks machen willst, musst du diesen
IP Stack also entsprechend vergewaltigen. Das geht - auch ohne
Aenderungen am Code - ist aber nicht sauber, nicht wirklich wartbar
und verlangt eine ausfuehrliche Dokumentation was wie warum und wieso
gemacht wurde.
> haben will, ist ein reines Implementierungsdetail. Einem Außenstehenden
Aus deiner Sicht.
> ist nicht zu vermitteln, warum er eine Information eintragen soll, die
> scheinbar nirgends verwendet wird und überhaupt keinen Einfluß auf das
> Systemverhalten hat.
"Weil das fuer die Funktoin notwendig ist. RTFM (Band 2, Kapitel 4,
Seite 82, Abschnitt 3 ¹)
Funktioniert idR. Sogar bei Fernmeldetechnikern.
¹ Bei manchen reicht die Drohung mit $VIEL_DOKU als Bluff aus.
Juergen P. Meier
Das ist leider keine Zukunftsmusik mehr. Die Realitat hat uns schon
laengst eingeholt.
Netzwerkkarten, die still und heimlich Bestimmte Pakete (mit
zufaellig passendem UDP oder TCP Port) einfach so wegfiltern, weil sie
glauben damit direkt angesprochen worden zu sein (natuerlich nicht
konfigurier- oder Abschaltbar) und damit normale Kommunikation zum OS
das auf der Kiste laeuft steoren, sind schon laengst Alltag.
Immerhin kann man mit dem erworbenen Wissen um solch SuperTolle[tm]
dysfunktionale Hardware weitere Ausschlusskriterien bei der Auswahl
von Hardware im EK erstellen.
Juer'RealTek Billigkarten werden auch im Serverbereich wieder
interressant, wer haette das gedacht...'gen
Ingo van Lil
>> Mit dem "automatisch ermitteln" habt Ihr angefangen, davon war nie
>> die Rede. Die IP des Gateways ist völlig belanglos, die wird ohnehin
>> nur verwendet, um mittels ARP die MAC zu erfragen. Die MAC ist
>> vorgegeben, also brauche ich die IP nicht.
>
> Dann tausch mal die Netzwerkkarte.
Was hat die denn damit zu tun? Auf die Wahl der Netzwerkkarte hab ich
keinen Einfluß. Wenn ein Mainboard-Hersteller bspw. überall den Intel
82546-Gigabit-Controller von Intel einsetzt, der an den Management-Port
ausschließlich Pakete an Port 623 durchschleift, dann muß ich damit
leben. Und jetzt aus rein esoterischen Gründen "Das mach ich nicht mit!"
zu sagen, wäre einfach nur idiotisch -- dann sucht sich der Hersteller
eben einen anderen Zulieferer für Management Controller.
> Es wäre genauso sinnig, überall IP-Adressen statt DNS-Namen zu
> verwenden, weil man ja nur die IP-Adressen braucht.
Gutes Beispiel. Soll ich dem Nutzer verbieten, IP-Adressen einzustellen,
weil ich DNS-Namen viel praktischer finde? Was spricht dagegen, beides
zu unterstützen und dem Nutzer die Wahl zu lassen?
Tschau,
Ingo
Ingo van Lil
>> Aber vom Admin beide Parameter zu verlangen, obwohl einer vollkommen
>> ausreichte, wäre hanebüchener Unsinn -- immerhin wird im Normalfall nur
>
> Die Aussage "obwohl einer vollkommen ausreicht" ist schlicht falsch.
>
> Bei Paketrouting ueber ein OSI-Schicht-3 Protokoll wie IP muss die IP
> Adresse des routenden Gateways bekannt sein und konfiguriert werden.
Wozu?
Tschau,
Ingo
Patrick Schaaf
>Patrick Schaaf <mailer...@bof.de>:
>>
>> Das wird generell in den naechsten Jahren lustig [...]
>> http://www.heise.de/newsticker/meldung/77864
>Immerhin kann man mit dem erworbenen Wissen um solch SuperTolle[tm]
>dysfunktionale Hardware weitere Ausschlusskriterien bei der Auswahl
>von Hardware im EK erstellen.
Die Zeitabschaetzung bezog sich auf die Befuerchtung, dass es bei
"Markterfolg" der "Technologie" vielleicht bald nur noch sehr schwer
moeglich sein wird, im EK etwas Anderes zu bekommen.
Aber noch koennen wir hoffen.
Gruss
Patrick
Juergen P. Meier
Weil die Routingentscheidung in Schicht 3 gefaellt wird, und dort sind
nur Schicht-3 Addressen bekannt. Die Vermittlung zwischen Schicht-3
und den darunterliegenden Schichten (hier Etherenet) uebernimmt ein
eigenes, gesondertes Protokoll (hier ARP).
Konzeptionell und Prinzipiell.
Alles andere ist ein diese Konzepte und Prinzipien unterlaufender Hack.
Per Definition. Wie solche Hacks aussehen, wurde dir bereits
erklaert, ebenso welche Vor- und Nachteile es auf technischer wie
organisatorischer Ebene bringt, sie zu Implementieren.
Und ja, auch Linux kann man zum Routen zwingen, ohne die Gateway-IP
zu kennen - nicht nur bei unnumbered P2P-Interfaces.
Juergen P. Meier
> Oliver Schad schrieb:
>
>>> Mit dem "automatisch ermitteln" habt Ihr angefangen, davon war nie
>>> die Rede. Die IP des Gateways ist völlig belanglos, die wird ohnehin
>>> nur verwendet, um mittels ARP die MAC zu erfragen. Die MAC ist
>>> vorgegeben, also brauche ich die IP nicht.
>>
>> Dann tausch mal die Netzwerkkarte.
>
> Was hat die denn damit zu tun? Auf die Wahl der Netzwerkkarte hab ich
Dann aendert sich die MAC-Addresses des Routers, und du wird um 3 Uhr
Morgens aus dem Bett geklingelt, weil "$DEIN_PRODUKT nach dem Router-
Upgrade nicht mehr Geht!!!".
>> Es wäre genauso sinnig, überall IP-Adressen statt DNS-Namen zu
>> verwenden, weil man ja nur die IP-Adressen braucht.
>
> Gutes Beispiel. Soll ich dem Nutzer verbieten, IP-Adressen einzustellen,
> weil ich DNS-Namen viel praktischer finde? Was spricht dagegen, beides
> zu unterstützen und dem Nutzer die Wahl zu lassen?
Wuerdet ihr bitte keine Analogien zu ziehen versuchen, die voellig
disjunkt zueinander sind? Das funktioniert naemlich nicht.
Danke.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
Oliver Schad
Wie reagiert eigentlich der Host, wenn der Router ICMP an den Host
schickt und der Client die IP nicht kennt? Paketfiltern wird dann auch
ein bissl - äh - merkwürdig.
mfg
Oli
Florian Laws
> Ingo van Lil <ing...@gmx.de>:
>> Oliver Schad schrieb:
>>
>>>> Mit dem "automatisch ermitteln" habt Ihr angefangen, davon war nie
>>>> die Rede. Die IP des Gateways ist völlig belanglos, die wird ohnehin
>>>> nur verwendet, um mittels ARP die MAC zu erfragen. Die MAC ist
>>>> vorgegeben, also brauche ich die IP nicht.
>>>
>>> Dann tausch mal die Netzwerkkarte.
>>
>> Was hat die denn damit zu tun? Auf die Wahl der Netzwerkkarte hab ich
>
> Dann aendert sich die MAC-Addresses des Routers, und du wird um 3 Uhr
> Morgens aus dem Bett geklingelt, weil "$DEIN_PRODUKT nach dem Router-
> Upgrade nicht mehr Geht!!!".
Nö, der Server-Admin wird aus dem Bett geklingelt, weil der die Option,
das Default-Gateway per MAC einzustellen genutzt hat anstatt der von Ingo
ebenfalls vorgesehenen Option, das Gateway per IP einzustellen.
Klarer Fall von Selber Schuld.
Und für die Sparfüchse von Server-Herstellern, die meinen, es sei eine
gute Idee, Management-Hardware und Betriebssystem über das selbe
Netzwerk-Interface anzusprechen, man muss solche Server ja nicht kaufen.
Ingos Management-Hardware soll jedenfalls beides können.
Grüße,
Florian
Juergen P. Meier
> On 2006-09-08, Juergen P. Meier <nospa...@jors.net> wrote:
>> Ingo van Lil <ing...@gmx.de>:
>>> Oliver Schad schrieb:
>>>
>>>>> Mit dem "automatisch ermitteln" habt Ihr angefangen, davon war nie
>>>>> die Rede. Die IP des Gateways ist völlig belanglos, die wird ohnehin
>>>>> nur verwendet, um mittels ARP die MAC zu erfragen. Die MAC ist
>>>>> vorgegeben, also brauche ich die IP nicht.
>>>>
>>>> Dann tausch mal die Netzwerkkarte.
>>>
>>> Was hat die denn damit zu tun? Auf die Wahl der Netzwerkkarte hab ich
>>
>> Dann aendert sich die MAC-Addresses des Routers, und du wird um 3 Uhr
>> Morgens aus dem Bett geklingelt, weil "$DEIN_PRODUKT nach dem Router-
>> Upgrade nicht mehr Geht!!!".
>
> Nö, der Server-Admin wird aus dem Bett geklingelt, weil der die Option,
> das Default-Gateway per MAC einzustellen genutzt hat anstatt der von Ingo
> ebenfalls vorgesehenen Option, das Gateway per IP einzustellen.
> Klarer Fall von Selber Schuld.
Daran wird sich beim $KUNDEN nur niemand erinnern. Darauf wette ich
einen Kasten Bier.
> Und für die Sparfüchse von Server-Herstellern, die meinen, es sei eine
> gute Idee, Management-Hardware und Betriebssystem über das selbe
> Netzwerk-Interface anzusprechen, man muss solche Server ja nicht kaufen.
ACK.
Ingo van Lil
>>> Bei Paketrouting ueber ein OSI-Schicht-3 Protokoll wie IP muss die IP
>>> Adresse des routenden Gateways bekannt sein und konfiguriert werden.
>>
>> Wozu?
>
> Weil die Routingentscheidung in Schicht 3 gefaellt wird, und dort sind
> nur Schicht-3 Addressen bekannt. Die Vermittlung zwischen Schicht-3
> und den darunterliegenden Schichten (hier Etherenet) uebernimmt ein
> eigenes, gesondertes Protokoll (hier ARP).
Richtig. Die Routing-Entscheidung wird geräteintern anhand einer
Phantasie-MAC getroffen, und ARP-Requests werden durch einen statischen
Eintrag übererflüssig gemacht. Mag sein, daß dieser Entscheidungsprozeß
so nicht vorgesehen ist, aber das Resultat ist in jedem Fall ein
gültiges und standardkonformes Paket.
Der Router wiederum trifft seine Routingentscheidungen anhand der
Ziel-IP im Paket.
Tschau,
Ingo
Ingo van Lil
>> Wozu?
>
> Wie reagiert eigentlich der Host, wenn der Router ICMP an den Host
> schickt und der Client die IP nicht kennt?
Er wird diese Nachrichten ignorieren. Dessen bin ich mir bewußt, darauf
habe ich in <slrnefq8n0...@ivl.my-fqdn.de> bereits hingewiesen.
> Paketfiltern wird dann auch ein bissl - äh - merkwürdig.
An welcher Stelle? Im Gerät oder auf dem Router?
Tschau,
Ingo
Juergen P. Meier
> Juergen P. Meier schrieb:
>
>>>> Bei Paketrouting ueber ein OSI-Schicht-3 Protokoll wie IP muss die IP
>>>> Adresse des routenden Gateways bekannt sein und konfiguriert werden.
>>>
>>> Wozu?
>>
>> Weil die Routingentscheidung in Schicht 3 gefaellt wird, und dort sind
>> nur Schicht-3 Addressen bekannt. Die Vermittlung zwischen Schicht-3
>> und den darunterliegenden Schichten (hier Etherenet) uebernimmt ein
>> eigenes, gesondertes Protokoll (hier ARP).
>
> Richtig. Die Routing-Entscheidung wird geräteintern anhand einer
> Phantasie-MAC getroffen, und ARP-Requests werden durch einen statischen
Falsch.
Es werden keine Routingentscheidungen anhand von irgendwelchen MAC
Adressen getroffen
> Eintrag übererflüssig gemacht. Mag sein, daß dieser Entscheidungsprozeß
Ja.
> so nicht vorgesehen ist, aber das Resultat ist in jedem Fall ein
> gültiges und standardkonformes Paket.
Das Paket an sich ist natuerlich standardkonform aufgebaut, es ist nur
nicht standardkonform geroutet worten.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
Ingo van Lil
>> Richtig. Die Routing-Entscheidung wird geräteintern anhand einer
>> Phantasie-MAC getroffen, und ARP-Requests werden durch einen statischen
>
> Falsch.
>
> Es werden keine Routingentscheidungen anhand von irgendwelchen MAC
> Adressen getroffen
Mein Fehler: Ich meinte natürlich eine Phantasie-IP. Eben jene 1.1.1.1,
für die ich eine Host-Route auf eth0 lege, die ich als Ziel der
Default-Route eintrage und die ich mit einem permanentem ARP-Eintrag auf
die eingestellte Gateway-MAC mappe.
>> so nicht vorgesehen ist, aber das Resultat ist in jedem Fall ein
>> gültiges und standardkonformes Paket.
>
> Das Paket an sich ist natuerlich standardkonform aufgebaut, es ist nur
> nicht standardkonform geroutet worten.
Mein Gerät verhält sich also nach außen hin korrekt und genau wie
gewünscht. Was intern passiert, ist für den Nutzer uninteressant.
Tschau,
Ingo
Oliver Schad
Der Router kriegt immer das gleiche zu sehen, es kann also nur um den
Host gehen, der hinter dem Router sitzt.
Ich verstehe immer noch nicht, warum du was implementieren willst, was
niemand realistischerweise braucht, gegebenenfalls für Verwirrung sorgt
und in einigen Szenarien Probleme bereitet.
mfg
Oli
Ingo van Lil
> Ich verstehe immer noch nicht, warum du was implementieren willst, was
> niemand realistischerweise braucht, ...
Hab ich schon das Sideband-Interface des Intel 82546-Chips erwähnt, auf
dem ich kein ARP verwenden kann, weil ich die Antworten nicht zu Gesicht
bekomme?
Tschau,
Ingo
Mario 'BitKoenig' Holbe
>> Wie reagiert eigentlich der Host, wenn der Router ICMP an den Host
>> schickt und der Client die IP nicht kennt?
> Er wird diese Nachrichten ignorieren. Dessen bin ich mir bewußt, darauf
Das ist nicht korrekt. Du kannst prinzipiell ja von jedem Router der
Deine Pakete weiterleitet ICMP-Nachrichten bekommen und deren IPs kennst
Du regelmaessig nicht.
Das einzige was da moeglicherweise zuviel ignoriert wuerde waeren ICMP
redirects oder so Spaesse. Und die *muss* man sowieso nicht beachten.
regards
Mario
--
We are the Bore. Resistance is futile. You will be bored.
Mario 'BitKoenig' Holbe
>> Es werden keine Routingentscheidungen anhand von irgendwelchen MAC
Naja, genaugenommen wird eine Routing-Entscheidung aufgrund
irgendwelcher mysterischen Algorithmen getroffen, die dazu ganz
verschiedene Parameter dazu heranziehen koennen.
Sehr verbreitet ist eine Algorithmenvariante, die zur Entscheidung die
Ziel-IP im zu routenden Paket und ein Tabelle mit IP-Netzen,
zugehoerigen Routern, Metriken und noch ein paar anderen Flags verwendet.
> für die ich eine Host-Route auf eth0 lege, die ich als Ziel der
> Default-Route eintrage und die ich mit einem permanentem ARP-Eintrag auf
> die eingestellte Gateway-MAC mappe.
Und diese sehr verbreitete Algorithmenvariante voraussetzend machst Du
dann genau das :)
>> Das Paket an sich ist natuerlich standardkonform aufgebaut, es ist nur
>> nicht standardkonform geroutet worten.
Was ist denn bitte standardkonformes Routing?
Ja, ich weiss - ist eine Frage an Juergen, ich will nur nicht fuer ne eh
rethorische Frage noch nen eigenes Posting absetzen.
regards
Mario, Deine Geduld bewundernd :)
--
Tower: "Say fuelstate." Pilot: "Fuelstate."
Tower: "Say again." Pilot: "Again."
Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..."
Bastian Blank
> teile des Traffics dabei abzwacken, und lokalen Management-Prozessoren
> zustellen, selbst wenn der Rechner selbst "aus" ist.
BCM57XX können das bereits, allerdings nur nach expliziter Konfiguration
auf einer IP.
Bastian
Paul Muster
> Netzwerkkarten, die still und heimlich Bestimmte Pakete (mit
> zufaellig passendem UDP oder TCP Port) einfach so wegfiltern, weil sie
> glauben damit direkt angesprochen worden zu sein (natuerlich nicht
> konfigurier- oder Abschaltbar) und damit normale Kommunikation zum OS
> das auf der Kiste laeuft steoren, sind schon laengst Alltag.
>
> Immerhin kann man mit dem erworbenen Wissen um solch SuperTolle[tm]
> dysfunktionale Hardware weitere Ausschlusskriterien bei der Auswahl
> von Hardware im EK erstellen.
Welche Karten von welchen Herstellern sind das konkret?
Danke & mfG Paul