Pi-Gateway: "RTNETLINK answers: File exists" bei ifup eth0 und Keepalive-Abbrüche nach dem Booten
Von English mit KI übersetzt ·
Erster Beitrag, ich lese hier schon eine Weile mit.Wir haben für eine kleine Umspannstation ein eigenes Gateway auf einem Raspberry Pi 3B+ (Raspberry Pi OS Bullseye) gebaut: Es liest drei Modbus-RTU-Zähler aus und veröffentlicht die Daten auf v1/gw/telemetry. Das Stationsnetz hat kein DHCP, deshalb braucht eth0 eine statische Adresse. Ich habe Folgendes in /etc/network/interfaces ergänzt:
auto eth0
iface eth0 inet static
address 10.40.2.20
netmask 255.255.255.0
gateway 10.40.2.1
dns-nameservers 10.40.2.1
Nach einem Neustart funktioniert es manchmal und manchmal nicht. Wenn es nicht funktioniert, meldet sudo ifup eth0:
RTNETLINK answers: File exists
ifup: failed to bring up eth0
In Hermetry zeigt der Log-Tab des Gateways bei jedem Start eine Trennung wegen keepalive_timeout. Danach verbindet es sich einige Minuten später wieder, oder gar nicht, bis ich mich vor Ort anmelde. ip addr zeigt manchmal zwei Adressen auf eth0, die statische und eine 169.254er-Adresse.
First post, I have been reading here for a while.
We built our own gateway on a Raspberry Pi 3B+ (Raspberry Pi OS Bullseye) for a small substation: it reads three Modbus RTU meters and publishes them on v1/gw/telemetry. The substation LAN has no DHCP, so eth0 needs a static address. I added this to /etc/network/interfaces:
auto eth0
iface eth0 inet static
address 10.40.2.20
netmask 255.255.255.0
gateway 10.40.2.1
dns-nameservers 10.40.2.1
After a reboot it sometimes works and sometimes not. When it does not, sudo ifup eth0 says:
RTNETLINK answers: File exists
ifup: failed to bring up eth0
In Hermetry the gateway’s Log tab shows a keepalive_timeout disconnect around every boot and then it reconnects some minutes later, or not at all until I log in on site. ip addr sometimes shows two addresses on eth0, the static one and a 169.254 one.
Von English mit KI übersetzt ·
Hast du zuerst ifdown und dann ifup ausprobiert?
Did you try ifdown first and then ifup?
Von English mit KI übersetzt ·
Ja, ifdown meldet interface eth0 not configured, und ifup schlägt danach genauso fehl.
Yes, ifdown says interface eth0 not configured and ifup fails the same way afterwards.
Von English mit KI übersetzt ·
Bullseye verwendet dhcpcd für die Netzwerkkonfiguration. /etc/network/interfaces ist die alte Methode, ich würde beides nicht mischen.
Bullseye uses dhcpcd for networking. /etc/network/interfaces is the old way, I would not mix them.
Von English mit KI übersetzt ·
Daniel hat recht. Ich hatte genau dieses Problem letztes Jahr auf einem Pi in einer Pumpstation. Zwei Dinge konfigurieren eth0: dhcpcd startet beim Booten, findet keinen DHCP-Server, weist dem Port eine Link-Local-Adresse 169.254.x.x sowie Routen zu, und dann versucht ifup, seine eigene Adresse und Standardroute hinzuzufügen. Die Route existiert bereits, daher antwortet der Kernel mit „File exists“ und ifup gibt auf. Je nachdem, welcher Prozess beim Booten das Rennen gewinnt, kommt das Gateway hinaus oder nicht.Entscheiden Sie sich für eines. Unter Bullseye heißt das dhcpcd. Entfernen Sie den eth0-Block aus /etc/network/interfaces (die Datei enthält dann nur noch die Zeile source) und legen Sie das statische Setup in /etc/dhcpcd.conf ab:
interface eth0
static ip_address=10.40.2.20/24
static routers=10.40.2.1
static domain_name_servers=10.40.2.1
noipv4ll
Anschließend ohne Neustart aufräumen:
sudo ip addr flush dev eth0
sudo systemctl restart dhcpcd
ip addr show eth0
noipv4ll verhindert die 169.254-Adresse. Wenn Sie später auf Bookworm umsteigen, ist dhcpcd entfernt, und Sie machen dasselbe mit nmcli. Notieren Sie sich das deshalb.
Daniel has it. I hit exactly this on a pumping station Pi last year. Two things are configuring eth0: dhcpcd starts at boot, finds no DHCP server and gives the port a 169.254 link-local address plus routes, and then ifup tries to add its own address and default route. The route is already there, so the kernel answers „File exists“ and ifup gives up. Depending on which one wins the race at boot, your gateway gets out or not.
Pick one. On Bullseye that means dhcpcd. Remove the eth0 block from /etc/network/interfaces (leave the file with only the source line) and put the static setup in /etc/dhcpcd.conf:
interface eth0
static ip_address=10.40.2.20/24
static routers=10.40.2.1
static domain_name_servers=10.40.2.1
noipv4ll
Then clean up without a reboot:
sudo ip addr flush dev eth0
sudo systemctl restart dhcpcd
ip addr show eth0
noipv4ll stops the 169.254 address. If you move to Bookworm later, dhcpcd is gone and you do the same with nmcli, so keep a note of that.
Von English mit KI übersetzt ·
Ich wusste nicht, dass sich das bei den Pi OS-Versionen geändert hat, gut zu wissen.
Didn’t know the Pi OS versions changed this, good to know.
Von English mit KI übersetzt ·
Behoben. Die Interfaces-Datei wurde bereinigt, in dhcpcd.conf steht die statische Konfiguration mit noipv4ll. Ich habe den Pi heute Morgen zehnmal hintereinander neu gestartet, und das Gateway hat sich jedes Mal innerhalb weniger Sekunden verbunden. Der Log-Tab zeigt jetzt pro Start genau eine saubere Verbindung.
Fixed. Interfaces file cleaned, static config in dhcpcd.conf with noipv4ll, rebooted the Pi ten times in a row this morning and the gateway connected within a few seconds every time. The Log tab now shows one clean connect per boot.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.

