Moin,
folgendes: Ich habe in einem OpenWRT Linux-Modul zwei "Netzwerkkarten"
und will diese (zum Test) back-to-back verbinden. Das klappt auch schon
so weit ich das sehen kann. Link ist da und beim Init der Karten werden
ein paar Pakete hin und her geschickt, die jeweils bei der anderen Karte
im RX Counter auftauchen.
Nun will ich da mal ein bisschen Durchsatz machen und ein paar Daten
rüber schieben, das gestaltet sich als schwieriger als gedacht.
eth0 bekommt z.B. 192.168.1.1 und eth1 z.B. 192.168.1.2. Wenn ich nun an
.1.2 Daten schicke ist Linux natürlich schlau und schiebt die nicht über
die Netzwerkkarte, sondern leitet die direkt intern an das Interface.
Frage: Wie kann ich ihn dazu zwingen die Daten über das andere Interface
zu schicken?
Gleich vorab: Ich kann das Modul nicht mit einem anderen Modul/Rechner
verbinden, da ich nur ein Modul habe und testen will, ob ich zwei Module
back-to-back ohne Übertrager verbinden kann. Daher verbinde ich es mit
sich selbst.
Fabian S. schrieb:> Wenn ich nun an> .1.2 Daten schicke ist Linux natürlich schlau und schiebt die nicht über> die Netzwerkkarte, sondern leitet die direkt intern an das Interface.> Frage: Wie kann ich ihn dazu zwingen die Daten über das andere Interface> zu schicken?
Das ist alles andere als einfach, Du musst viele Teile der
Linux-Netzwerkkonfiguration manuell ändern. Das fängt schon beim ARP an
und geht beim Routing weiter.
> und testen will, ob ich zwei Module> back-to-back ohne Übertrager verbinden kann. Daher verbinde ich es mit> sich selbst.
Du willst nur die Übertrager loswerden? Warum das? Die gehören bei
Ethernet aus gutem Grund mit dazu.
Hmm, hatte gehofft, dass man da mit ein paar iptables weiter kommt. Soll
ja nur ein quick-and-dirty Test sein ;)
Naja, soweit ich weiß braucht man die Übertrager nicht unbedingt. Es
gibt nicht ohne Grund App-Notes von Intel und TI (habe ich bislang
gefunden), wie es auch ohne geht. Hauptsächtlich ist das ja, um
Potentialausgleiche zu machen, keine GND-Loops zu bekommen, Common-Mode
Reject und damit die Arbeitspunkte der Sender/Empfänger unterschiedlich
eingestellt werden können. Ich muss nur über 2cm übertragen, Sender und
Empfänger sind die gleichen Chips. Alles tuti :)
Hier das von Intel:
http://www.intel.com/content/dam/doc/application-note/8255x-fast-ethernet-controllers-without-magnetics-appl-note.pdf
Man merke, dass der hier benutzte Intel-Chip Push-Pull-Treiber hat, was
die wenigsten haben. Daher muss man die 50R an die Versorgung hängen, wo
normal der Trafo dran hängt, bei mir 2V.
Und das von TI:
http://www.ti.com/lit/an/snla088a/snla088a.pdf
Wo man sich meiner Meinung nach in meinem Fall auch die Kondensatoren
und ein paar Widerstände sparen kann, da beide Chips mit dem gleichen
DC-Offset arbeiten. Somit reicht bei mir eine Durchverbindung und 4
Pull-Ups nach 2V. Aber das will ich ja gerade testen.
Hmm, Du hast also so ein Mini-Modul, welches zwar die Pins für 2
Ethernet-Schnittstellen bereitstellt, die Übertrager und Buchsen aber
auf nem extra Board dazugebaut werden müssen. Du willst Dir jetzt das
extra Board mit den Übertragern sparen, korrekt?
Ok, das könnte bei kurzen Leitungen und identischen ICs schon gehen.
Zu Deinem Übertragungstest: Du könntest Raw Ethernet Pakete senden. Dann
ist der IP-Stack von Linux außen vor. Such mal im Internet, gibt einige
Programme die das können. Z.B. packeth.
Fabian S. schrieb:> eth0 bekommt z.B. 192.168.1.1 und eth1 z.B. 192.168.1.2.
Wäre es nicht günstiger, wenn beide NICs wenigstens in unterschiedlichen
Subnets lägen?
Gerd E. schrieb:> Hmm, Du hast also so ein Mini-Modul, welches zwar die Pins für 2> Ethernet-Schnittstellen bereitstellt, die Übertrager und Buchsen aber> auf nem extra Board dazugebaut werden müssen. Du willst Dir jetzt das> extra Board mit den Übertragern sparen, korrekt?
Ja. Genaugenommen will ich zwei Module auf ein Baseboard setzen.
Rufus Τ. F. schrieb:> Wäre es nicht günstiger, wenn beide NICs wenigstens in unterschiedlichen> Subnets lägen?
Weiß ich nicht, wie schicke ich dann Daten von A nach B? Das Problem
bleibt ja das gleiche. Wenn ich Daten von A nach B schicken will und die
IP von B nutze werden die Daten einfach intern verarbeitet. Auch hier
die Frage: Wie zwinge ich ihn dann, die Daten über das Interface von A
zu schicken?
Wahrscheinlich ist Dein Linux so schlau, weil die Defaultroute sagt daß
Traffic von 0.0.0.0/0 über eth0 gehen soll.
Lege beide NICs in verschiedene Netzblöcke, zB ins 192er und 10er; dann
setze Routen. Sicherheitshalber kannst Du noch mit iptables den Traffic
per Interface reglementieren.
Womit testet Du das denn? Schau mal ob das Tool an ein Interface/IP
binden kann (wget, curl, nc). Notfalls bastelt man sich halt zwei
Scripts die das machen.
nic schrieb:> Wahrscheinlich ist Dein Linux so schlau, weil die Defaultroute sagt daß> Traffic von 0.0.0.0/0 über eth0 gehen soll.>> Lege beide NICs in verschiedene Netzblöcke, zB ins 192er und 10er; dann> setze Routen. Sicherheitshalber kannst Du noch mit iptables den Traffic> per Interface reglementieren.>> Womit testet Du das denn? Schau mal ob das Tool an ein Interface/IP> binden kann (wget, curl, nc). Notfalls bastelt man sich halt zwei> Scripts die das machen.
Hmmm joa ok, das habe ich quasi so schon probiert - mehr oder weniger.
Also wenn ich beide Interfaces erstelle hat er natürlich zwei Routen für
jedes der Netzwerke über das entsprechende Interface. Ob das nun zwei
NICs sind oder nicht, ist m.E. nach egal, bin aber auch kein Experte.
Selbst wenn ich dann zwei NICs habe, erstellt er ja je ein Routing
Eintrag für das jeweilige Netzwerk. Diese müsste ich ja umgehen/löschen,
damit er eben Pakete die an Netz A gehen sollen, nicht über das
zugehörige Interface rausgehen. Aber wenn dann über das Interface ein
Paket rein kommt (z.B. ein Ping) und der Rechner schickt die Antwort
raus, geht die ja auch wieder über Interface über die der Ping
ürsprünglich raus gegangen ist oder?
Ich habe von Netzwerktechnik nur bedingt Ahnung und bekomme hier den
übelsten Knoten im Hirn :D
Konrad S. schrieb:> Es reicht, wenn man die Source-IP vorgibt. Beispiel:> ...
Zwei Sachen: Ist das nur ein Fehler gewesen, dass es beim 2. Befehl
hinten .2.2 heißt? Oder habe ich was übersehen?
Und dann läuft auf der Kiste wie gesagt OpenWRT, sprich nur Busybox nc,
was soweit ich das eben rausfinden konnte kein -s und kein -l kann,
zudem gibt es lsof nicht. Gut, letzteres könnte ich vermutlich mit
einbauen, aber das Busybox nc kann kein Server.
Eine ähnliche Idee hatte ich aber auch schon: Und zwar kann man quasi
das gleiche auch bei ping machen mit -I. Wenn ich dort jedoch ein
Interface oder eine IP angebe bekomme ich nie ne Antwort, nicht mal wenn
ich ein ping an die IP des gleichen Interfaces mache. Keine Ahnung was
da schief läuft.
Naja, ich sehe schon, das ist nicht mal eben so mit meinen
Netzwerkkenntnissen gemacht. Falls keiner mehr ne fast-and-easy Lösung
hat, muss ich halt warten, bis das zweite Modul kommt, dann probiere ich
das damit.
> Es reicht, wenn man die Source-IP vorgibt. Beispiel:
Leider reicht das nicht, der Kernel routet trotzdem lokal. Kann man ganz
einfach überprüfen indem man das Kabel (bei Wlan die Antenne) abzieht.
Oder die erreichten Übertragungsraten messen, die liegen (bei einem
nicht-uralten System) weit jenseits dessen, was die echte Hardware
hergibt.
Fabian S. schrieb:> Zwei Sachen: Ist das nur ein Fehler gewesen, dass es beim 2. Befehl> hinten .2.2 heißt? Oder habe ich was übersehen?
Sorry, das war ein "Copy&Waste"-Fehler.
> Und dann läuft auf der Kiste wie gesagt OpenWRT, sprich nur Busybox nc,> was soweit ich das eben rausfinden konnte kein -s und kein -l kann,> zudem gibt es lsof nicht. Gut, letzteres könnte ich vermutlich mit> einbauen, aber das Busybox nc kann kein Server.
Ja, Busybox. Da wird's schnell mal eng.
> Eine ähnliche Idee hatte ich aber auch schon: Und zwar kann man quasi> das gleiche auch bei ping machen mit -I.
Das habe ich als erstes probiert.
> Wenn ich dort jedoch ein> Interface oder eine IP angebe bekomme ich nie ne Antwort, nicht mal wenn> ich ein ping an die IP des gleichen Interfaces mache. Keine Ahnung was> da schief läuft.
Hat auf 'nem ausgewachsenen Linux problemlos funktioniert.
Hmm naja, danke für die Tips, scheint aber nicht so recht zu
funktionieren. Wollte auch gerade mal mit den Routen rumspielen und
schauen, ob ich ihn überzeugt bekomme da was zu machen, aber das
funktioniert aus einem mir vollkommen schleierhaften Grund auch nicht.
Wenn ich versuche ne Route zu löschen, bekomme ich nur
1
# route del 192.168.1.0
2
route: SIOCDELRT: No such process
Keine Ahnung, was da im OpenWRT schon wieder schief läuft :-/
Fabian S. schrieb:> Hmm naja, danke für die Tips, scheint aber nicht so recht zu> funktionieren. Wollte auch gerade mal mit den Routen rumspielen und> schauen, ob ich ihn überzeugt bekomme da was zu machen, aber das> funktioniert aus einem mir vollkommen schleierhaften Grund auch nicht.> Wenn ich versuche ne Route zu löschen, bekomme ich nur>
Fabian S. schrieb:> Ich nehme mal an, dass auch hier Busybox das nicht überstützt...
Korrekt.
Du musst das ip-full Package in OpenWRT installieren und, falls nicht
schon aktiviert, beim Kernel kompilieren den Network Namespace Support
aktivieren.
Mir ist nicht ganz klar, was du von mir willst? Wenn du die routing
Tabelle haben willst, solltest du mir sagen welche Konfiguration ich
vorher einstellen soll.
Mit Routingtabellenmanipulationen kommst Du nicht weiter. Lokal (in
einem Network Namespace) bekannte IP-Adressen werden nie über ein
Interface geroutet.
Fabian S. schrieb:> Mir ist nicht ganz klar, was du von mir willst? Wenn du die routing> Tabelle haben willst, solltest du mir sagen welche Konfiguration ich> vorher einstellen soll.
Wenn das Löschen einer Route aus der Routingtabelle fehlschlägt, ist es
vermutlich nicht die schlechteste Idee, erst einmal in die Inhalte
dieser Routingtabelle zu schauen.
Lukas S. schrieb:> Ich hab zwar glaubich deine Frage nicht ganz verstanden, aber vieleicht> suchst du das hier: https://wiki.ubuntuusers.de/Netzwerkbr%C3%BCcke
Ähhh ja und vermutlich nein :P
Dann würden die Pakete ja im Kreis wandern :D Die Brücke zwischen den
beiden Netzwerkkarten habe ich ja schon in Hardware.
Also nochmal anders: Ich habe zwei Netzwerkkarten in einem Rechner, die
Über ein Cross-Over Kabel verbunden sind. Ich will diese Verbindung nun
testen. Wie schicke ich Daten über die Leitung, ohne dass diese direkt
intern ans Ziel geschickt werden, denn das Ziel ist der Rechner ja
selbst.
Fabian S. schrieb:> Also nochmal anders: Ich habe zwei Netzwerkkarten in einem Rechner, die> Über ein Cross-Over Kabel verbunden sind. Ich will diese Verbindung nun> testen. Wie schicke ich Daten über die Leitung, ohne dass diese direkt> intern ans Ziel geschickt werden, denn das Ziel ist der Rechner ja> selbst.
Indem man eine Virtuelle Maschine (VM) aufsetzt und der diese Karte
komplett übergibt. Auf einem modernen PC kein Problem, auf ARM geht das
IMHO eher nicht so ohne weiteres.
Grrr... ist ja nett gemeint, aber bitte wenigstens die Ursprüngliche
Frage richtig lesen. Ich habe hier ein Linux-MODUL! auf dem OpenWRT
läuft, das ist ein MIPS Prozessor mit gerade mal 16MB Flash, da läuft
nie ne VM drauf...
Sheeva P. schrieb:> Fabian S. schrieb:>> Da listet er mir brav die Routing-Tabelle auf.>> Ja, ich weiß. Deswegen ja auch die Frage.Fabian S. schrieb:> Mir ist nicht ganz klar, was du von mir willst?
Ist das denn so schwer zu verstehen? Die Routing-Tabelle natürlich.
Wie schon gesagt wird eine lokale (innerhalb eines Network Namespaces)
Adresse nie über ein Interface geroutet. Das Einzige was Du noch tun
könntest, wenn es nur darum geht festzustellen, ob die Verbindung
funktioniert, wäre einen RAW-Socket zu verwenden, diesen an das
Netzwerkinterface zu binden und über diesen dann Ethernet-Päckchen
direkt zu versenden. Mittels tcpdump & Co könntest Du dann üerprüfen, ob
diese auf dem anderen Interface ankommen.
Vieleicht könntest du mal hping probieren: das erzeugt am Kernel vorbei
Netzwerk-Pakete(Und kann somit u.a. Ip adressen fälschen). Und dann mit
tcpdump überprüfen.
Thread beobachten
Seitenaufteilung abschalten