Verzögern Sie die Zuweisung der IP-Adresse, bis das Netzwerkadaptergerät verfügbar ist

1203
sonicwave

Ich arbeite an einer benutzerdefinierten Embedded-Platine mit drei Ethernet-Schnittstellen:

  • eth0 und eth1 sind in der CPU integriert (ein TI AM3356)
  • eth2 wird mit einem integrierten LAN9512-Chip (mit dem Treiber smsc95xx) hergestellt, der über USB angeschlossen ist

Beim Booten möchte ich eth0 und eth1 ohne IP-Adresse (sie werden für Industrial Ethernet verwendet) und eth2 mit einer IP-Adresse (wird für Standardnetzwerkkommunikation verwendet).

Mein /etc/network/interfacesursprünglich sah so aus:

auto lo iface lo inet loopback  auto eth0 iface eth0 inet manual pre-up ifconfig $IFACE up post-down ifconfig $IFACE down  auto eth1 iface eth1 inet manual pre-up ifconfig $IFACE up post-down ifconfig $IFACE down  auto eth2 iface eth2 inet static  address 10.1.1.10  netmask 255.255.255.0  gateway 10.1.1.20  

Dadurch werden alle drei Netzwerkschnittstellen (und der Loopback-Adapter) aufgerufen, die angegebene IP-Adresse wird jedoch nicht an eth2 zugewiesen.

Durchsuchen des Bootlogs bekomme ich die Nachricht

ip: Gerät 'eth2' kann nicht gefunden werden

... und kurz danach eine Nachricht vom smsc95xx-Treiber, dass eth2 registriert wurde. Ich nehme an, es liegt daran, dass eth2 nicht verfügbar ist, wenn das init-Skript versucht, ihm die IP-Adresse zuzuweisen (stattdessen kurz darauf auftaucht).

Wenn ich die Karte ifup eth2einmal gestartet habe, wird die IP-Adresse automatisch korrekt zugewiesen.

Ich habe versucht, mit ein paar pre-upSachen herumzuhacken, und Folgendes scheint gut zu funktionieren:

auto eth2 iface eth2 inet static  address 10.1.1.10  netmask 255.255.255.0  gateway 10.1.1.20  pre-up while [ ! -e /sys/class/net/eth2 ]; do sleep 1; done; 

Aber es fühlt sich einfach zu sehr an wie ein Hack (und hängt auch das System, wenn eth2 nie auftaucht).

Gibt es eine "richtige" Möglichkeit, die IP-Zuweisung zu warten, bis die Schnittstelle tatsächlich vorhanden ist? - oder muss ich dazu ein benutzerdefiniertes Skript erstellen?

Beachten Sie, dass ich an einem eingebetteten Linux (Kernel 3.18.9-rt5, der mit PTXDist erstellt wurde) und mit BusyBox arbeite. Daher habe ich möglicherweise keinen Zugriff auf alle verfügbaren Tools.

3
Hast du "udev"? MariusMatutiae vor 8 Jahren 0
@MariusMatutiae Ja, das tue ich. Ich habe es jedoch nur zum Einrichten eines benutzerdefinierten Namens für ein USB-Laufwerk verwendet. Wäre es auch für die Einstellung der IP geeignet? sonicwave vor 8 Jahren 0
`udev` kann ein Skript auslösen, wenn ein Gerät erscheint. Ihr Skript kann dann die IP zuweisen. LawrenceC vor 8 Jahren 0
@LawrenceC Ich habe heute früher ein wenig mit "udev" experimentiert - ich glaube, ich habe eine Arbeitsregel eingerichtet, aber ich konnte nicht "/ sbin / ifup eth2" (entweder das oder "ifup") ausführen wird nicht erfolgreich abgeschlossen). Ich werde weiter probieren, wenn ich am Montag wieder im Büro bin. sonicwave vor 8 Jahren 0
Da es sich wie auf Debian anhört, könnten Sie einfach einen `sleep 10 hinzufügen. ifup eth2` in Ihr `/ etc / rc.local` und das könnte funktionieren. LawrenceC vor 8 Jahren 0
@LawrenceC Ich habe es mit udev zu tun bekommen - stellte sich heraus, dass BusyBox das richtige Arbeitsverzeichnis für sein 'ifup' benötigte oder dass der Pfad eingerichtet wurde (was wahrscheinlich der Grund war, warum `ifup 'ursprünglich nicht von` udev' funktionierte ) - siehe meine eigene Antwort für die Details. sonicwave vor 8 Jahren 0

2 Antworten auf die Frage

2
sonicwave

Am Ende fügte ich udevmeiner local.rulesDatei die folgende Regel hinzu :

KERNEL=="eth2", SUBSYSTEM=="net", SUBSYSTEMS=="usb", DRIVERS=="smsc95xx", RUN+="/home/bin/enableeth2.sh" 

Das Skript ( /home/bin/enableeth2.sh) enthält Folgendes (und ist als ausführbar definiert):

#!/bin/bash cd /sbin/ ifup eth2 

Beachten Sie die Änderung des Verzeichnisses /sbin/vor dem Aufruf ifup, anstatt nur aufzurufen /sbin/ifup eth2. Dies ist erforderlich, da die BusyBox intern ifupaufruft ip(befindet sich in /sbin/) und da der Pfad beim Ausführen der udevRegel anscheinend nicht eingerichtet ist. ifupBeim Versuch, die eigentliche Einrichtung des Adapters vorzunehmen, wird ein Fehler ausgegeben.

1
MariusMatutiae

Am besten beschleunigen Sie die Benutzeroberfläche. Dies wird erreicht, indem Sie allow-hotplug eth2unmittelbar auto eth2in der Zeilengruppe von hinzufügen /etc/network/interfaces.

Laut Debian Anleitung ,

"Auto" -Startoberfläche beim Systemstart

"allow-auto",,

"allow-hotplug" -Startschnittstelle, wenn der Kernel ein Hotplug-Ereignis von der Schnittstelle erkennt

Also sollte es so sein:

auto eth2 allow-hotplug eth2 iface eth2 inet static  address 10.1.1.10  netmask 255.255.255.0  gateway 10.1.1.20  

Bearbeiten

Möglicherweise benötigen Sie eine udevRegel für ifupdie Schnittstelle, wenn udev sie erkennt. Möglicherweise verwenden Sie eine Regel wie:

KERNEL=="sd*", ATTRS=="Yoyodyne", ATTRS=="XYZ42", ATTRS=="123465789", RUN+="/path/to/my/script" 

indem Sie es in eine Datei einfügen /etc/udev/rules.d. Dies gilt für ein USB-Objekt. Hersteller und Modell müssen in Ihrem Fall behoben werden. Die Datei /path/to/my/scriptist eine ausführbare Datei, die enthält

#!/bin/bash ifup InterfaceName 

Das sollte es tun.

Danke für den Vorschlag, aber es hilft nicht. Mit "allow-hotplug eth2" anstelle von "auto eth2" wird "eth2" beim Booten überhaupt nicht angezeigt. Als Referenz funktioniert "ifup eth2" nach dem Booten weiterhin (und weist die angegebene IP-Adresse zu), und ich bekomme auch nicht mehr die Meldung "ip: kann das Gerät nicht finden" eth2 "". sonicwave vor 8 Jahren 0
@sonicwave Ich habe einen Fehler gemacht, bitte sehen Sie meine redigierte Antwort MariusMatutiae vor 8 Jahren 0
Hmm - Ich bin mir ziemlich sicher, dass ich das schon probiert habe - und dass es sich darüber beschwert hat, dass der "allow-hotplug" "falsch platziert" wurde, wenn er nach der "auto eth2" -Zeile platziert wurde - und dann die Datei einfach komplett ablehnte. Ich versuche es am Montag noch einmal, wenn ich wieder im Büro bin, um sicherzugehen. Danke aber auf jeden Fall! sonicwave vor 8 Jahren 0
@sonicwave Sie sehen, das oben Gesagte schlägt das Debian-Handbuch wörtlich vor. Wenn dies nicht funktioniert, liegt ein Problem vor. Wir können es mit einer Ad-hoc-Udev-Regel versuchen, aber das ist wieder ein Hack, weil es so funktionieren soll, wie ich es oben beschrieben habe, ohne dass ein weiteres Eingreifen erforderlich ist. MariusMatutiae vor 8 Jahren 0
Hmm - Ich habe mir kurz den Busybox-Code angesehen, und er scheint "allow-hotplug" nicht zu unterstützen - was vermutlich erklärt, warum er nicht funktioniert ... sonicwave vor 8 Jahren 0
@sonicwave Mmmmh, ich bin ein bisschen überrascht: Ich erinnere mich, dass busybox Hotplug unterstützt hat. Googling "busybox allow-hotplug" gibt Code-Änderungen zurück, die auf 2005-2007 zurückgehen. MariusMatutiae vor 8 Jahren 0
@sonicwave Pls lesen meine Bearbeitung. MariusMatutiae vor 8 Jahren 0
Ich habe auch einen Patch gefunden, der versucht, Unterstützung für "allow-hotplug" hinzuzufügen, aber anscheinend wurde er nie zusammengeführt. Der aktuelle Baum scheint zumindest kein Anzeichen dafür zu haben. Auf jeden Fall habe ich es erstmal mit "udev" und dem Skript, das es ruft, zum Laufen gebracht. Danke für die Eingabe! sonicwave vor 8 Jahren 0