Daten zwischen zwei Netzwerkkarten, ein Rechner

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?

Es reicht, wenn man die Source-IP vorgibt. Beispiel:

Server auf *.2:

1

nc -l 192.168.1.2 2345

Client auf *.1:

1

nc -s 192.168.1.1 192.168.2.2 2345

Überprüfung:

1

lsof -n -i -a -p `pgrep -d, -x nc`

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.

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 :-/

g457 schrieb:
> Leider reicht das nicht, der Kernel routet trotzdem lokal.

Upps!
Das macht er sogar bei unterschiedlichen Subnets.

Thorsten schrieb:
> Das geht indem Du ein Interface in einen anderen Network Namespace
> packst.
>
> man ip-netns

1

# ip netns list

2

BusyBox v1.23.2 (2015-12-15 21:26:31 CET) multi-call binary.

3

4

Usage: ip [OPTIONS] {address | route | link | } {COMMAND}

5

6

ip [OPTIONS] OBJECT {COMMAND}

7

where OBJECT := {address | route | link | }

8

OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] }

Ich nehme mal an, dass auch hier Busybox das nicht überstützt...

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
>

1

# route del 192.168.1.0

2

> route: SIOCDELRT: No such process

Du willst ja eine Route auf ein Netzwerk löschen:

1

# route del -net 192.168.1.0

Fabian S. schrieb:
>

1

# route del -net 192.168.1.0

2

> route: SIOCDELRT: Invalid argument

Was sagt denn "route -n"?

Da listet er mir brav die Routing-Tabelle auf.

Fabian S. schrieb:
> Da listet er mir brav die Routing-Tabelle auf.

Ja, ich weiß. Deswegen ja auch die Frage.

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.

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.

Ich hab zwar glaubich deine Frage nicht ganz verstanden, aber vieleicht 
suchst du das hier: https://wiki.ubuntuusers.de/Netzwerkbr%C3%BCcke

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 gesagt, ich weiß nicht für welche Konfiguration du das haben willst. 
Hier mal zwei Beispiele:

1

root@OpenWrt:/# route

2

Kernel IP routing table

3

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

4

192.168.3.0     *               255.255.255.0   U     0      0        0 eth1

5

root@OpenWrt:/# ifconfig eth0 192.168.1.1

6

root@OpenWrt:/# ifconfig eth1 192.168.1.2

7

root@OpenWrt:/# route

8

Kernel IP routing table

9

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10

192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

11

192.168.1.0     *               255.255.255.0   U     0      0        0 eth1