PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : 2 Netzwerkkarten - IP per DHCP



mustafaB
15.04.01, 15:15
Hallo Linuxler!


hab ein kleines Problem.

System ist Suse 7.0 (Personal)

Es sind 2 Karten im System:

1.) eth0 Realtek, wird von Suse direkt unterstützt
2.) eth1 D-LINK 530 TX, habe ich den Treiber runtergeladen, kompiliert, und hochgeladen... funktioniert!

Wenn ich beide Netzwerkkarten mit statischen IP`s starten lasse, sind beide Karte OK, und funktionieren auch auf dem Netz.

Sobald ich aber DHCP(dhcpcd) auf der D-Link karte starte, wird diese zu eth0, und die Realtek karte verabschiedet sich mit einem Fehler.
Das Problem ist auch, das ich gar keine IP Adresse bekomme auf der DLINK.

Kennt jemand einen anderen alternativen DHCP Client, der zuverlässig funktioniert?

Stelle mir das so vor:

Starte kiste mit statischen IP`s.
Und dann Manuell dhcp auf die DLINK karte starten... wer kennt nen guten dhcp client?


Viele Grüsse

Mustafa

Bauchi
15.04.01, 23:03
schon mal dran gedacht, den mac adressen FESTE ip adressen zuzuordnen ?
würd ich versuchen ...

mustafaB
16.04.01, 12:25
Hallo


Leider ist das nicht möglich.
Da die Kiste als Router/Firewall gebraucht wird, und ich die externe IP per DHCP beziehen muss (per Cablemodem).

Jemand Ideen?

gruss
Musa

andreas.jurenda
17.04.01, 23:53
Ich hab das gleiche Problem, zwar mit anderen Karten (isapnp-ne2000 auf eth0 und pci-3com-3c900b auf eth1).
natürlich auf SuSE 7.0

Ich hab das ganze an den SuSE-Support weitergeleitet, bin gespannt was da rauskommt.

Ursache dabei ist die sehr seltsame :mad: boot-Prozedur von SuSE-7.0!

Nachdem ich alles rausgeräumt hatte und die beiden Karten mit dem YAST neu konfiguriert hatte und dann keinen (!) Neustart provoziert habe, konnte ich händisch die beiden Karten in Betrieb nehmen, und dabei erfolgreich dhclient starten!
Das ging irgend wie mit:
/sbin/init.d/network start
/sbin/init.d/dhclient start

Entscheidend ist hier die Reihenfolge!

Die beiden Scripte network und dhclient gehen nämlich ohne Rücksicht auf anderweitige Einstellungen einfach der Reihe nach alle vier möglichen eth's durch. Dabei wird der ersten auftretenden Karte beim Aufruf von ifconfig die Nummer 0 zugewiesen, der nächsten die Nummer 1 und so weiter.

Beim Beim Booten läuft das dann in alphabetischer Reihenfolge ab, weshalb zuerst dhclient und erst danach network aufgerufen wird. :eek:

Die Folge davon ist dann, das zuerst alle Karten mit dhcp und danach erst die Karten mit fixer ip an ifconfig geliefert werden. ifconfig seinerseits bringt dann die eth-Nummern so durcheinander, daß dann die 2. Karte als eth0 in ifconfig eingetragen ist.

Ob es eine Lösung ist, die init-Scripte umzubenennen, damit network vor dhclient gestartet wird, bin ich mir nicht sicher, denn mir sind die Abhängigkeiten nicht bekannt.

Derzeit hab ich das ganze durch feste Zuordnung der ip's gelöst. So lange mein Provider die ip's nicht ändert wird's funktionieren :cool:

Herzliceh Grüße von Juri :-})

pitu
18.04.01, 12:36
Ahm seltsame bootprozedur?
Juri:

Die Scripte gehen der Reihe nach die Einstellungen in der rc.config durch, in dieser Reihenfolge werden die ip-adressen den Netzwerkkarten zugeordnet.

Du hast Recht, das booten lauft in alphabethischer Reihenfolge. Genauergesagt nach alphanummerischer Reihenfolge.
Ausgefuehrt werden die Script in den Unterverzeichnissen ./rc<x>.d/. S* beim starten und K* beim stoppen.

Allerdings hast du in sofern Recht, dass dhclient die Nummer 02 und network die Nummer 05 hat.

Leider kann ich nur fuer die 7.1 sprecen, da ich im Moment nicht auf eine 7.0 zugreifen kann, aber die Scripten sollten gleich sein.:



# Search for interfaces to be configured from rc.config
DHCP_DEVS=""
for I in $NETCONFIG; do
eval IFCONFIG=\$IFCONFIG$I
test "$IFCONFIG" = "dhcpclient" &#0124;&#0124; continue
eval NETDEV=\$NETDEV$I
DHCP_DEVS="$DHCP_DEVS $NETDEV"
done

also, aus der rc.config wird $NETCOFIG eingelesen. In NETCONFIG stehen die Devices, die an ifconfig uebergeben werden.
In NETCONFIG stahen immer _0 _1 etc.
Dies ist wichtig fuer die IFCONFIG-Variablen, die lauten: IFCONFIG_0 etc.

Also, NETCONFIG wird gelesen, der Reihe nach an I uebergeben. Das heisst, dass bei jedem Schleifendurchgang $I= _0 dann _1 (je nach NETCONFIG) hat.

Also wird bei jedem durchgan eine IFCONFIG_$I durchsucht.

In IFCONFIG_$I steht entweder ein ifconfig-Parameter fuer eine feste IP oder "dhcpclient.
Wenn dhcpclient drinsteht, wird es an eine Liste von Devices angehaengt, die mit DHCP konfiguriert werden sollen.

Die Reihenfolge der Devices ist Abhaengig von der Reihenfolge in NETCONFIG, hat aber nichts mit den Karten zu tun, da in NETDEV immer(!!!) das dazugehoerige Device, egal ob dhcpclient oder feste IP mit angegeben ist.

Im weitern Verlauf des Scripts werden alle Devices aus der eben erstellten Liste mit DHCP konfiguriert, keine die eine feste IP haben.

Im network-Script wird zuerst getestet, ob in IFCONFIG_$I dhcpclient oder bootp steht, wenn ja, wird es ignoriert, bzw bootp ausgefuehrt.

Dann wird geschaut, ob das Device ippp* ppp* isdn* hat, dann wird auch ignoriert, und spaeter von anderen Scripten abgearbeitet,

und erst dann wird alles andere mit fester IP an ifconfig uebergeben.

Die Reihenfolge der Scripte ist damit egal, da beide unterschiedliche Devices abarbeiten.

Die Devices (eth*, etc) sind uebrigens fest an die IPs gebunden, d wird nix durcheinandergeschmissen:



#
# networking
#
# number of network cards: "_0" for one, "_0 _1 _2 _3" for four cards
#
NETCONFIG="_0"#
# IP Adresses
#
IPADDR_0="10.10.11.137"#
# network device names (e.g. "eth0")
#
NETDEV_0="eth0"#
# parameteres for ifconfig, simply enter "bootp" or "dhcpclient" to use the
# respective service for configuration
# sample entry for ethernet:
# IFCONFIG_0="10.10.11.137 broadcast 10.10.255.255 netmask 255.255.0.0 up"
#
IFCONFIG_0="10.10.11.137 broadcast 10.10.255.255 netmask 255.255.0.0 up"


Das sind die entsprechenden Teile aus der /etc/rc.config.

Der Support wird warscheinlich nicht darauf Antworten, da es sich nicht mehr um Installationssupport handelt.


mustafaB:
Welche Karte eth0 und welche eth1 ist, legst du in der /etc/modules.conf fest. sieht dann folgendermassen aus:


# Aliases - specify your hardware
alias eth0 Treibername
alias eth1 Treibername


Die Scripten weisen nun diesen Devices (etc0, eth1) wie es eben in der rc.config festgelegt ist (NETDEV_* IFCONFIG_*) Adressen zu oder rufen DHCP auf.



for DEV in $DHCP_DEVS; do
ifconfig $DEV down &>/dev/null
ifconfig $DEV 0.0.0.0 up
done


das ist der Teil aus dem dhclient script, der die Devices mit DHCP startet.
$DHCP_DEVS wurde oben definiert, und dort stehen fest die Devices drin, die mit DHCP gestartet werden sollen.

Bei dir in deinem Beispile steht dort eth1 drin.

Denke eher das ist ein Problem deines Treibers.

Die 530 TX ist uebrigens eine ganz normale Tulip-Karte.

thorsten

andreas.jurenda
06.05.01, 20:38
Hallo Thorsten:

Zuerst danke, danke, danke, für Deine unzähligen Beiträge in diesem Forum. Ich lese seit November 2000 sehr viel hier im Forum und es kommen von Dir immer gute Antworten.
Ich hoffe, Du wirst seitens SuSE auch entsprechend bedankt ;)

Der Installationssupport hat die erwartete Ablehnung zur Beantowrtung der Frage geschickt.

*** schnipp | kurzer Einschub ***
Dazu muß ich sagen, das dies absolut falsch ist. Ich habe mir extra deshalb die SuSE 7.0 Professional zugelegt, die speziell auch für Internet/Intranet ausgelegt ist. In allen Supportbestimmungen sind ausdrücklich nur die Bedingungen für den 60-Tage-Support angegeben! Bei der Pro-Version sind es 90-Tage und ich gehe davon aus, daß die Pro-Version (dafür gibts die ja!) auch einen umfangreicheren Support bietet, denn sonst wäre diese Version mit den "Serverkomponenten" ohne Support nicht sehr sinnvoll. Darüber hinaus verstehe ich nicht, wenn Support für Modem, für Netzwerkkarte, aber nicht für 2 Netzwerkkarten geleistet wird???????
*
Warum kauft sich jemand ein SuSE-Linux? Alle (die paar, dies nicht trifft, sind sehr wenige!) kaufen sich's weil sie einen frei konfigurierbaren Rouzter brauchen! Alle, die sich Linux kaufen, brauchen ein Werkzeug, und kein Spielzeug!!! Ich habe sehr aufmerksam alles das gelesen, was SuSE bezüglich Firewall, Masquerading, Router,.... und so weiter schreibt: ich finde das eine Frechheit, denn damit grenzt SuSE alle jene aus, die sich das Produkt kaufen.
Wohlgemerkt: wer ein Einzelplatzsystem braucht kauft sich ein Windoof!
*
Leider hat SuSE dadurch keine Möglichkeit, Fehler auszumerzen, die bei Usern auftreten, denn hier hätte es einen Bug zum Reparieren gegeben!
*** schnipp | Einschub Ende ***

So, jetzt möchte ich wieder zum Thema zurückkommen!

Unter SuSE 7.0 pro haben die beiden Scripts die gleiche Nummer!
Beide haben S40... bzw. K40... deshalb meine alphabetische Reihenfolge, die numerische war mir sowieso klar!

Thorsten: Ahm seltsame bootprozedur?
Seltsam deshalb, weil ich fast einen vollen Tag gebraucht habe, bis ich den für mich immer noch etwas schwer verständlichen bash-Code entschlüsselt hatte. Seltsam auch deshalb, weil ich die Geschichte etwas verwirrend empfinde und man da leicht den Überblick verliert. Seltsam auch, weil ich mit den Nummern sehr an meine TGM-Zeiten vor 20 Jahren erinnert wurde, wo ich meine ersten Basic-Programme auf einem TRS80 geschrieben habe. Da hat man auch bei den Zeilennummern 10, 20, 30, ... genommen, damit man nachher noch Zeilen einfügen konnte ;)

Danke für Deine Ausführungen zu dhclient und network. Das hab ich auch so gesehen,

ABER:
Es gibt einen gewaltigen Unterschied zwischen sequentieller und wahlfreier (paralleler) Ausführung (Zugriff)!

Die beiden angesprochenen Scripts gehen davon aus, das ifconfig wahlfrei ist. Also bei Angabe von eth1 sollte auch eth1 gemeint sein, auch wenn eth0 noch nicht (!) angesprochen wurde! Leider ist dem nicht so!

Im laufenden Betrieb, kann ifconfig ganz normal auf die entsprechenden eth's zugreifen. Da gibts keine Probleme.

Beim Initialisieren der eth's, also beim erstmaligen Aufruf von ifconfig (in der Regel beim booten des Rechners) werden Teile von ifconfig "falsch" zugeordnet. Beim ersten Aufruf werden, auch wenn eth1 angesprochen wird, Teile mit eth0 verbunden. Beim zweiten Aufruf, um eth0 zu konfigurieren, werden Teile mit eth1 verbunden. Da ich eine ISA_PNP und eine PCI-Netzwerkkarte habe, konnte ich das ganz gut erkennen, weil die IRQ'S und die E/A's ganz toll vermischt waren!

Die Startscrippts von SuSE machen hier einen folgenden Ablauf (bei 7.1 wurde dies durch die Nummern 02 und 05 sogar fundamental unterstrichen!):

dhcp:
__ loop eth0 bis eth3
____ wenn dhcp
______ dann ifconfig dhcp ... ethx
__ end loop
network:
__ loop eth0 bis eth3
____ wenn nich(dhcp)
______ dann ifconfig fix-ip ... ethx
__ end loop
fertig

So lange das ifconfig nicht repariert ist, müßte es aber so aussehen:

ethernet:
__ loop eth0 bis eth3
____ wenn dhcp
______ dann ifconfig dhcp ... ethx
______ sonst ifconfig fix-ip ... ethx
__ end loop
fertig

Die gesamte Geschichte funktioniert derzeit nur dann, wenn die eth0 mit dhcp arbeitet und erst die eth1 mit einer fixen IP.

Da haben wir aber nun den Punkt, wo es sehr sehr DUMM wird, denn bei dhcp gibt es auch den Fall, daß der entsprechende Server down ist. In diesem Fall funktioniert der gesamte Netzwerkverkehr nicht mehr!!! Denn auch die eth1 wird nun falsch und unbrauchbar konfiguriert!

Bei entsprechender inteligenter Konfiguration:
* eth0 als lokales Netzwerk mit fixer-ip und
* eth1 als Internetzugang mit dhcp
wäre ich auf der sicheren Seite, wenn der "virtuelle" Zugang über dhcp als 2. Netzwerkkarte kommt. Das lokale Netzwerk funktioniert immer, auch wenn die eth1 wegen fehlender Verbindung zusammenbricht. Leider scheitert dieser "inteligente" Ansatz wegen der "SELTSAMEN" bootprozedur.

Möglicherweise ist diese Beschreibung auch die Ursache dafür, warum es so viele Probleme mit den ISDN-Karten gibt, die ja eigentlich auch wie eine "virtuelle" Netzwerkkarte funktionieren. Die entsprechende IP gibts ja nur dann, wenn die Karte online ist. Also muß hier ständig ifconfig mit dhcp aufgerufen werden! Bei falscher Reihenfolge beim booten des Rechners steigt ifconfig aus!

Herzliche Grüße von Juri :-})

PS: meine verspätete Antwort beruht auf einem gravierenden Problem mit Phonehome und einer Win2000-Kiste.

[ 06. Mai 2001: Beitrag editiert von: Juri ]