Řešení „Odpovědi RTNETLINK: Soubor existuje“ při spuštění ifup

Pokud řešení poskytované @ theoB610 stále nefunguje , pak možná budete muset zařízení wlan0 propláchnout před ifup a ifdown.

sudo ip addr flush dev wlan0 

Toto není problém příliš specifický pro Raspberry Pi, podobný problém nastal a byl vyřešen v kabelových sítích v zde (odkud jsem odvodil řešení mého problému s Pi).

Komentáře

• Tento problém jsem měl server HP ProLiant (!), a to to opravilo.
• Skvělé řešení. Základním problémem je nějaká předchozí konfigurace, automatická nebo manuální (například spuštění ifconfig z řádku cmd), stále přetrvává. Chřipka Příkaz sh tuto situaci opravuje.
• Tento problém jsem měl, když existují poškozené /etc/sysconfig/network-scripts/ifcfg-* soubory způsobené tím, že NetworkManager nemá rád některá nastavení a vytváří náhradní soubor, čímž vytváří několik dalších souborů a způsobení chyby RTNETLINK answers: File exists. Odstranění poškozených (ty, které se ' t nezobrazují jako profil) se jeví jako oprava.
• Nikdy to nekopírujte a nevkládejte na produkční server. Nahradil jsem wlan0 za eth0 a rozhraní okamžitě selhalo a ' se nechtěl vrátit.
• Zajímavé, že nikdo neposkytl nejjednodušší a podle pravidla nejbezpečnější metodu : reboot. Například s proplachovacím rozhraním jsem měl potíže – moje rozhraní / IP selhalo a mohl jsem se připojit pouze přímo na konzoli … takže restart je pro mě vždy způsob, jak s tím jít.

Myslím, že řešení lze najít v tomto příspěvku na blogu Řešení „RTNETLINK odpovědi: Soubor existuje ”při spuštění ifup ; určitě to pro mě opravilo.

V zásadě můžete mít v souboru rozhraní přiřazenu pouze jednu bránu. Odstraňte všechny duplicitní řádky, které určují bránu, aby se zobrazil pouze jednou.

Upraveno / etc / network / interfaces file:

auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.2 netmask 255.255.255.0 gateway 192.168.1.1 iface wlan0 inet static address 192.168.1.3 netmask 255.255.255.0 #gateway 192.168.1.1 <= Either comment or remove this line 

Veškerá zásluha společnosti Lennart za vyřešení tohoto problému!

Komentáře

• Na tuto odpověď narazil přes Google. To je to, co pro mě fungovalo na virtuálním počítači s Ubuntu na Hyper-V
• Přijměte svoji vlastní odpověď kliknutím na zaškrtnutí na levé straně. Pouze toto dokončí otázku a nebude se znovu objevovat rok co rok.

Vyřešil jsem autor:

sudo ifup --ignore-errors wlan0 

po tomto příkazu ifdown a ifup začaly fungovat správně.

Komentáře

• To je užitečné po " restartu sítě služeb ", díky. 🙂

kroky:

1 kontrola-> ip route (je-li výchozí nastavení trasy IP jiné než požadované rozhraní, postupujte podle 2.d & 3. kroku)

2 sudo ip route del default (smazat výchozí rozhraní)

3 sudo ip route add default via ip_address dev interface_name (přidejte požadované rozhraní takto)

V mém případě jsem měl stále spuštěné jiné připojení – jakmile jsem toto rozhraní stáhl s ifdown eth0, přišlo to, o které jsem se zajímal (wlan0) čistě.

Nedoporučuji používat možnost –ignore-errors

Narazil jsem na to, když jsem se pohrával s VMWare vCenter.Pokud jste na stejné lodi, měli byste mít nainstalované nástroje VMWare Tools, Perl a net-tools u správce balíčků před vytvořením šablony / snímku VM.

Používáme ifdown k odstranění RTNETLINK a ifup znovu

ifdown wlan0 ifup wlan0 

Vynutit de / konfiguraci

ifdown --force --verbose ethX && ifup --force --verbose ethX