Dotaz: Network-manager připojuje i odpojený drát

[Pavel 'TIGER' Růžička]

Většinu času mám notes v docku na drátu, ale dnes jsem jej potřeboval mimo dock a na WiFi. Po spuštění systému (Debian Jessie) naběhl desktop i WiFi, a tak jsem začal brouzdat internetem. Avšak po chvilce internet vypadl s hláškou stránka nenalezena. V nm-appletu jsem zpozoroval, že nově připojil i drát, který byl odpojen. Proto i IP byla naprosto nesmyslná. Stačilo však eth0 odpojit a v prohlížeči dát obnovit a mohl jsem brouzdat internetem dál. Zajímavé bylo, že během tohoto výpadku bylo možné procházet vnitřní sítí. Potom připojování a odpojování kabelu fungovalo, tak jak mělo. Ovšem problém se opakuje při každém spuštění (restartu) systému, pokud jsem na WiFi. Chvilku funguje a později připojí eth0, kterou musím ručně odpojit. Pak až do restartu funguje vše jak má. Prolezl jsem všechny možné logy, konfiguráky, dokonce jsem vlezl i do crontabu, ale nenalezl jsem důvod, proč po spuštění startuje i odpojenou eth0? Nesetkali jste se s něčím podobním?

lspci | egrep -i --color 'network|ethernet'

09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)

0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

Podle mne je to ale jen nějaký nepořádek v network-manageru.

||/ Název Verze Architektura Popis

+++-==============-============-============-=================================

ii network-manage 0.9.10.0-1 i386 network management framework (dae

---

---

Odpovědi

[Pavel 'TIGER' Růžička]

Pochopitelně je to zase nějaký bug v network-manageru. Wicd pracuje bez chyby.

[Šangala]

Setkal, někde jsem to i v OT diskuzi vzpomínal, ale s tím, že když jsem to třeba 10× připojil na drát a odpojil od drátu, tak se příšerně zpomalilo zbylé wifi připojení - bez NM to nedělalo (taky Debian :)).

[Jan R.]

Kedy ti to presne robi? Mna stve, ze sa u mna neschopnost browsovat objavuje tiez, ale odpoji sa wifi. Doteraz samotne odpojenie prebehlo vzdy, ked som bol dalej od PC (aj iba na minutu, system sa netvari, ze sa uspal) a preto neviem detaily.

Mam rovnaky wifi adapter, takze mozno chyba driveru? Pouzivas b43 alebo wl driver? Ja pouzivam b43 pod kernelom 3.13.0-34-generic #60-Ubuntu...

Inak network-manager mam verzie 0.9.8.8-0ubuntu7

[Pavel 'TIGER' Růžička]

Používám STA driver a jak jsem psal, dělalo mi to jen po startu systému.

[pavlix]

Pochopitelně je to zase nějaký bug v network-manageru.

K takovému závěru nevidím dostatek informací.

[Pavel 'TIGER' Růžička]

Připouštím, nešel jsem nikterak do hloubky. Leč rok to fungovalo bez problému a problémy nastaly až po update network manageru. V ten den se nic jiného neupdatovalo. Takže z logického hlediska jsem to svedl na něj. Možná jsem měl použít slůvko nejpravděpodobněji.

[pavlix]

Já osobně vidím problém už v popisu problému.

V nm-appletu jsem zpozoroval, že nově připojil i drát, který byl odpojen.

Vím, že takovéto metafory jsou hrozně cool, ale popravdě řečeno nemám nejmenší tušení, co tato věta znamená, zvláště v kontextu té následující.

Proto i IP byla naprosto nesmyslná.

Nevidím jediný logický důvod, proč by IP měla kdy být naprosto nesmyslná kromě zjevné chyby nebo porušení paměti. Adresa se nastavuje buď dle uživatelské konfigurace nebo dle dat z vnějšího zdroje.

Z celého popisu vůbec není zřejmé, které připojit a odpojit se týká fyzického kabelu a které profilu připojení a není vůbec jasné, zda byl během celé té akce připojený kabel či nikoliv.

Možná jenom špatně čtu a něco mi uniklo, ale celý ten popis je tak zmatečný, že mi přijde nesmyslné z něj vyvozovat jakýkoli závěr o jakémkoli software.

[Pavel 'TIGER' Růžička]

Asi si to jen nepochopil.

Byl jsem připojen pomocí WiFi mimo dock, do kterého je zapojen drát. To znamená, že drát byl fyzicky odpojen. Network Manager správně nejdříve připojil WiFi a vše fungovalo tak jak mělo, ale asi po čtyřech sekundách se rozhodl, že připojí i drát. Ale jelikož byl fizycky odpojen a byl nastaven na DHCP, tak pochopitelně obdržel nesmyslnou adresu (resp. lokálku). No a největším problémem bylo, že takhle špatně připojenému drátu dal vyšší prioritu, než WiFi. Proto přestalo všechno přes WiFi fungovat a rozeběhlo se to, až když jsem v NetworkManageru odpojil jím připojený drát, který byl fyzicky po celou dobu odpojen.

Je to lépe popsané ???

[pavlix]

Asi si to jen nepochopil.

Uznávám, že popsat správně chybu je umění, proto se to při skutečném hlášení chyb řeší doplňujícími dotazy.

Byl jsem připojen pomocí WiFi mimo dock, do kterého je zapojen drát. To znamená, že drát byl fyzicky odpojen. Network Manager správně nejdříve připojil WiFi a vše fungovalo tak jak mělo, ale asi po čtyřech sekundách se rozhodl, že připojí i drát.

Jaký význam má drát připojený do docku ve chvíli, kdy je notebook mimo dock?

Ale jelikož byl fizycky odpojen a byl nastaven na DHCP, tak pochopitelně obdržel nesmyslnou adresu

Jak může obdržet nesmyslnou adresu z DHCP, když je od sítě fyzicky odpojený?

No a největším problémem bylo, že takhle špatně připojenému drátu

V čem přesně spočívá špatné připojení drátu?

Proto přestalo všechno přes WiFi fungovat a rozeběhlo se to, až když jsem v NetworkManageru odpojil jím připojený drát, který byl fyzicky po celou dobu odpojen.

Pokud si dobře pamatuju, tak se NetworkManager řídí čistě podle toho, jak připojení/odpojení kabelu detekuje kernel. Dokonce mám pocit, že do toho nevstupuje ani udev.

[Šangala]

Uznávám, že popsat správně chybu je umění, proto se to při skutečném hlášení chyb řeší doplňujícími dotazy.

No i na těch dotazech by chtělo zapracovat…

Jaký význam má drát připojený do docku ve chvíli, kdy je notebook mimo dock?

No k tomu tak nějak dock slouží, že jsou tam připojeny „dráty“ a to furt.

V čem přesně spočívá špatné připojení drátu?

Já bych si tipl, že v tom, že jej NM „někam“ připojil aniž by bylo kam, bo se nemělo vůbec eth. používat…

Pokud si dobře pamatuju, tak se NetworkManager řídí čistě podle toho, jak připojení/odpojení kabelu detekuje kernel. Dokonce mám pocit, že do toho nevstupuje ani udev.

Ti si už jen tak OT rýpnu: pokud si já pamatuji, tak kdykoliv NM zlobil, tak ručně to normálě a kupodivu správně fungovalo…

[pavlix]

No i na těch dotazech by chtělo zapracovat…

Konstruktivní kritika je samozřejmě vítána, takže pokud najdeš špatně položený dotaz v bugzille, dej vědět. Tady tomu z principu nebudu věnovat tolik úsilí a času.

No k tomu tak nějak dock slouží, že jsou tam připojeny „dráty“ a to furt.

Tak by to asi zasloužilo upřesnit. Já osobně to vidím tak, že kabel zapojený do docku je odpojený od notebooku, jestliže je notebook odpojený od docku. Alespoň tak to běžně funguje. Důležité je, jestli to stejně vidí kernel, udev a NetworkManager (v tomto pořadí, udev jde v tomto případě možná vynechat).

Já bych si tipl, že v tom, že jej NM „někam“ připojil aniž by bylo kam, bo se nemělo vůbec eth. používat…

NetworkManager není robotická ruka, nepřepojuje kabely ani nevaří kafe.

Ti si už jen tak OT rýpnu: pokud si já pamatuji, tak kdykoliv NM zlobil, tak ručně to normálě a kupodivu správně fungovalo…

Asi už jsem v oboru příliš dlouho, takže na tom nic k podivení nevidím.

[Václav "Darm" Novák]

DHCP klient si už při neobdržení adresy nenastaví tu co měl naposledy nebo nějakou fallback adresu? Mně to tedy vzdy dělal.

[pavlix]

DHCP klient by pokud vím v případě neúspěchu nikdy neměl nastavit (standalone) ani předat (NetworkManager) starou adresu. Jak dhclient, tak NetworkManager umožňují používat IPv4 link-local adresy jako fallback (oproti link-local IPv6 adresám, které se používají souběžně).

To u NetworkManageru není default právě z důvodu, že jsou někteří neznalí uživatelé schopni adresu 169.254.x.x označit za nesmyslnou, ač stačí jeden dotaz do googlu, aby zjistili, co ten rozsah znamená. Pokud si dobře pamatuju, tak Windows mají tuto feature automaticky zapnutou.

Mně to tedy vzdy dělal.

Tak DHCP klient by už podle názvu měl sloužit k získání konfigurace pomocí protokolu DHCP. Jiná věc je, že některé programy takto označené mají ještě další funkce.

[Václav "Darm" Novák]

Ah, jsem blb. Ano, link-local adresy Windows nastavuje v základním nastavení, dhcpcd nebo dhclient pod Linuxem v některých distribucích taky. Ten fallback na poslední adresu jsme měli ručně dodělaný na jednoúčelových linuxových stanicích.

[pavlix]

Ah, jsem blb.

Až tak to vyznít nemělo.

Ano, link-local adresy Windows nastavuje v základním nastavení, dhcpcd nebo dhclient pod Linuxem v některých distribucích taky.

Přesně tak, ovšem to nelze vztáhnout na situaci, kdy dhclient/dhcpcd pouze dodávají informace jinému konfiguračnímu nástroji.

Ten fallback na poslední adresu jsme měli ručně dodělaný na jednoúčelových linuxových stanicích.

Ale fuj. Prasárny tohoto typu řeším věčně hlavně s lidma, co se nějak zabývají bootování z NFS na dynamicky konfigurované síti, přičemž systém spoléhá na funkci root FS na NFS a NFS spoléhá na to, že je síť staticky konfigurovaná.

[Pavel 'TIGER' Růžička]

Tak ona se ta privátka stává nesmyslnou, když program provádí úkon, který ani provádět nemá a přesto zobrazí takový výsledek.

[pavlix]

Nevím, čemu říkáš privátka a na jakém základě ji označuješ za nesmyslnou. Já jsem psal o link-local adrese, která nesmyslná není a navíc ji NetworkManager nastaví pokud vím jen na výslovné přání uživatele.

[Pavel 'TIGER' Růžička]

Ano máš pravdu, správně tam mělo být lokálka ... to je tak když se dělá více věcí najednou. Obávám se, že časy, kdy ji network manager nastavoval jen na výslovné přání jsou pryč. Teď to ověřit zrovna nemohu, ale mám za to, že už jsem se s tím setkal i v Linuxu, že v případě neúspěchu byla automaticky nastavena.

[pavlix]

Ano máš pravdu, správně tam mělo být lokálka...

Právě ta je naopak velmi dobře definovaná i dobře poznatelná.

Obávám se, že časy, kdy ji network manager nastavoval jen na výslovné přání jsou pryč.

Nikoliv. Dívám se do aktuálních zdrojáků a fakta jsou následující. Nejenom, že NetworkManager ve výchozí konfiguraci, tedy method=auto IPv4LL nepoužívá, ale oproti mým návrhům kombinaci DHCP a IPv4 dosud vůbec nepodporuje.

Vždy jsem měl za to, že v NetworkManageru stojí tolik věcí za hovno, že není potřeba si vymýšlet věci, které tam ani nejsou.

Teď to ověřit zrovna nemohu, ale mám za to, že už jsem se s tím setkal i v Linuxu, že v případě neúspěchu byla automaticky nastavena.

Věřím ti, při experimentování jsem se setkal opravdu s ledasčím. Jenže jsem nakonec v 95% nesmyslného chování systému musel na základě logů konstatovat souběh několika nástrojů či alespoň několika instancí NetworkManageru, tedy chybu v samotném testování.

Nicméně, ať už konkrétní problém vznikl neopatrným experimentováním se systémem nebo chybou v software, nevidím důvod vymýšlet konspirační teorie tam, kde ani neexistuje kód, který by k takovému chování vůbec směřoval.

[Pavel 'TIGER' Růžička]

Potřeboval jsem to rychle řešit, takže NM byl nahrazen WICD. Ten pracuje bez chyby, proto jsem usoudil, že to bude nějaký bug v NM. Kdyby to bylo v něčem jiném, nefungoval by pravděpodobně ani WICD, ne? Bohužel dobrá analýza ze vylučuje s rychlým řešením problému.

[pavlix]

Potřeboval jsem to rychle řešit, takže NM byl nahrazen WICD.

Chápu. Sám jsem WICD zkusil někdy před lety, už ani nevím proč. Teď koukám jako blázen, že mám na disku i klon jejich repozitáře. Ale párkrát jsem už přímo konfiguroval wpa_supplicant.

Kdyby to bylo v něčem jiném, nefungoval by pravděpodobně ani WICD, ne?

Vzhledem k tomu, že se WICD a NM neshodují ani v tom, jak komunikují s kernelem, lze očekávat naprosto cokoliv a problém může být od NM až po všechny komponenty, se kterými přímo či nepřímo komunikuje a nebo i v nějaké distribuční úpravě či konfiguraci. Obecně se mi tento předpoklad neosvědčil a v sítích tuplem ne.

Bohužel dobrá analýza ze vylučuje s rychlým řešením problému.

To se ani v nejmenším nevylučuje, jsou to dvě paralelní věci, ale to není tak podstatné. Za problém považuju, když se z prakticky nulové analýzy vyvozují nějaké zásadní závěry a ty se dále publikují navíc bez možnosti je jakkoli ověřit. Vytváří to velký prostor pro FUD a přitom to moc nepřidává na prostoru pro řešení.

[Pavel 'TIGER' Růžička]

Ale někde už jsem tu psal, že se to stalo po aktualizaci NM a jeho komponent. Nic jiného se neaktualizovalo. Takže to skutečně vidím jako problém v NM. Otázkou je, jestli to bylo v něm jako takovém, nebo jen distribuční úpravě. A jelikož se jedná o Jessie, tak bych vsadil na tu distribuční úpravu.

[pavlix]

Ale někde už jsem tu psal, že se to stalo po aktualizaci NM a jeho komponent.

To je o něco lepší indikátor a nejjednodušším ověřením je downgrade. To člověku umožňuje s relativní jistotou specifikovat poslední funkční a první nefunkční verzi.

Nicméně pokud to zamícháš s nesmysli jako je následující, tak tím značně snižuješ důvěryhodnost svých pozorování, protože člověk pak neví, která část diskuze je plkání a která je o nějakém skutečném problému.

Obávám se, že časy, kdy ji network manager nastavoval jen na výslovné přání jsou pryč.

Otázkou je, jestli to bylo v něm jako takovém, nebo jen distribuční úpravě. A jelikož se jedná o Jessie, tak bych vsadil na tu distribuční úpravu.

Balíčkování v Debianu mi přijde oproti RPM jako hrozný masochismus (a to RPM není kdovíjaký zázrak), ale pokud by člověk viděl diff mezi zdroji těch dvou balíků, třeba by z toho něco poznal.

[Jezekus]

Koukam cerna magie poslední dobou. Ja zas uz notnou chvili kdyz uspim notebook (vetsinou s kabelem) tak po probuzeni mi chybi eth0 a NM ho odmita pouzit. Uspim znovu a probudim znovu a vse zacne fungovat, ale pripadam si jak trotl. Akorat Fedora 20

[xxl]

Já zase když mám spuštěné vmware služby, tak po probuzení notebooku se network-manager připojí na jednu z virtuálních vmware "drátových" sítí a je spokojený. Musím spojení ručně shodit a ručně se připojit na opravdové drátové rozhraní.

[Šangala]

Dobrá informace, bo na desktopu kde to používám, NM letěl po dvou dnech hraní se zprovozněním sítě (už je to hodně dávno), tak kdybych si to švihl do NTB, kde NM (zatím) mám, tak abych se nedivil .

[xxl]

Tak už to, zdá se, funguje správně. Stačí si postěžovat, provést upgrade a je to.

[pavlix]

Mimochodem, do podobného problému se opírám delší dobu a udržuju si vlastní patch, nemáš k tomu po ruce více informací?

[xxl]

Obávám se, že moje informace k problému nebudou dostačující.

Dokud to dělalo tu chybu, chovalo se to tak, že po probuzení notebooku po chvilce naběhla ikonka, že je jako k dispozici síťové připojení po drátu. Ale nic nefungovalo. Podivil jsem se, podíval jsem se na drátová připojení (2x vmnet a opravdový ethernet) a byl jsem připojen k jednomu z rozhraní vmnet. Kliknul jsem, že se to má odpojit a pak nechal připojit síť na opravdovém ethernetu. Ten naběhl a do dalšího probuzení to bylo v pořádku. Choval jsem se k tomu jako mírně poučený BFU (ví kde kliknout).

Nevím, kdy to přestalo chodit, ale patrně bych našel, kdy (s jakou verzí) se to zase rozchodilo.

[pavlix]

Nevadí. Mně osobně ani tak nejde o verze jako aby se tyhle věci v gitu vychytaly a do budoucna mě to neotravovalo.

[xxl]

Nedalo by se do NM přidělat klikátko na "Privacy extensions" pro IPv6? Sice se to dá ručně do (zatím stále ještě textového) konfiguračního souboru doplnit, ale jedno klikátko navíc by to spravilo. Všiml jsem si, že v konfiguraci bridge se takové klikátko objeví.

[pavlix]

Nedalo by se do NM přidělat klikátko na "Privacy extensions" pro IPv6?

NetworkManager v posledních letech žádné klikátko nedistribuuje a existuje několik samostatných projektů, takže je potřeba se obrátit na konkrétní GUI projekt, který tě zajímá.

[xxl]

Aj, aj ... tak pardón

[pavlix]

Dokonce mám pocit, že každou chvíli přijde někdo s nápadem napsat si zase jedno nové ;).

[pavlix]

po probuzeni mi chybi eth0 a NM ho odmita pouzit

Pokud chybí eth0, tak je asi správně, že ho NM odmítá použít, ne? :)

[lertimir]

Tohle s network managerem nesouvisí. Podle mne to je otázka nahrání firmware do síťové karty po vzbuzení a její korektní inicializace. Ta karta může být ve stavu, že inicializační soft se s ní nemusí domluvit.

Kdysi (asi před 5 lety) jsem měl zkušenost z notebookem, který měl dual boot s XP, pokud se z XP přecházelo do linuxu (openSUSE cca 10.1) rebootem, tak linux neviděl eth0. Pokud se notebook vypnul a zapnul, tedy byl nenulový čas, kdy karta byla bez napájení, linux identifikoval eth0. Vysvětluji si to tak, že po rebootu, byla karta v nějakém neobvyklém stavu, s nímž nebyl schopen se driver domluvit.

[honza_c]

Mám stejný problém. Debian Sid 64bit + KDE4, čerstvá instalace. Thinkpad x200s, Intel Corporation Ultimate N WiFi Link 5300.

Zapnu notebook, drát mám odpojený. nm se připojí k wifi, normálně funguju. Do dvou až tří minut se nm připojí k drátové síti, IM, prohlížení webu a další věci přestanou fungovat. Musím se ručně odpojit a pak všechno funguje. Až do té doby, než notebook vypnu, nebo i uspím. Na drátě nemusím být připojený vůbec, i tak se ale několikrát za den musím odpojit.

Pár dní zpátky jsem googlil, zda se někdo nesetkal s něčím podobným, ale nic jsem nenašel a network manageru nerozumím natolik, abych kontroloval a upravoval konfiguráky. Buďto to v Debianu opraví, nebo přejdu na wicd.

[pavlix]

Dokážu pochopit, že NM ignoruje stav toho kabelu, protože to je feature po které strašně moc lidí toužilo a na Fedoře ji snad aktivuje NetworkManager-config-server, nevím jak to mají na Debianu, ale to je až u relativně nových verzí. Co mě překvapuje víc je, že by to drátové připojení uspělo. K tomu by musel být nějaký zjevný důvod typu zapnutého IPv4LL nebo tak něco, ale IPv4LL adresy snad člověk na první pohled pozná, ne?

[pavlix]

Oprava... NetworkManager kombinaci DHCP a IPv4LL zjevně dosud nepodporuje ani v git master, tudíž takovou situaci sám o sobě nevytvoří, viz 34.