DHCP-vel bootkor nem konfigurálodik, kézzel bármikor

Ubuntu Linux

Sziasztok!

egy igen szokatlan dolgot vettem észre, egyre nagyobb gyakorisággal előálló problémaként. Ubuntum, amit egyébként kezdek végre rendesen belakni, a bootolás folyamatában "elfeledi" feléleszteni a hálókártyát rajta a hálózatot. driverek betöltődnek, ezzel nincs is baj. de "network unreachable" üzenetet kapok belépés után. ez nem lenne meglepő, ha pl. nem is tudnák kézzel felhúzni, mert akkor nyilván van más gond. viszont ha kézzel kiadom az /etc/init.d/network restart parancsot, akkor szépen rendesen felépül.

van valakinek hasonló tapasztalata? olyasmire gondolok, hogy "túl kevés ideig" vár a dhcp kliens arra, hogy megkapja az ip címet, vagy esetleg rosszkor. a jó ég tudja. mindenesetre a telepítéskor ilyen jelenség nem volt. azóta viszont szépen elszaporodott (ha nem az ubuntut bootolom, akkor ilyen gondom NINCS!). próbáltam az indító scripteket értelmezni, de én nem látom az okot, ami megmagyarázhatná ezt a jelenséget.

azt viszont tudom, hogy ha pl. a deb bootol, de bármi okból nem kap ipt elég gyorsan, akkor próbálkozik még picit. nem adja fel egyből. tény, hogy az ubuntu gyorsabban bootol, de én inkább várok még 5 mp-et, de kicsit nevetséges, hogy kézzel élesztgessem a hálózatot.

ja, hogy slusspoénja is legyen: mintha ipv6 címe lenne az interface-nek, bár ehhez nem értek, csak hát az a sor "ki van töltve" ifconfig hatására. sőt, amikor először láttam a jelenséget, akkor csak a loop dev volt bekonfigolva, kézzel indítva a kérdéses scriptet mégis lett.

van valakinek valami elképzelése mit lehetne tenni?

[ubuntu dapper drake, kernel 2.6.15-18, chellos kábelen jövő delej. integrált intel gigabites kártya, bár ez sztem nem számít, mert a kártya működik]

  • 1793 megtekintés

( cspeti | 2006. 03. 15., sze – 17:29 )

Hali!

Nekem is ez a problémám. Az is előfordul hogy 5-6 alkalommal is ki kell adnom a /etc/init.d/networking restart parancsot mire megjön az IP-m.
Most én is Dapperrel nyomulok de ugyan ez a gondom megvolt Breezyvel is. A szolgáltatónál egyébként nemrég lett dinamikus az IP cím.Eddig fix volt, de azt is dhcp adta. Akkor be kellett állítanom fixen a konfiguráláskor mert egyébként nem vette fel a rendszer az IP címet csak nagyritkán. 1ébként ha ilyenkor bebootolok egy winxp-t az simán felveszi az IP-t.

( Xterm v | 2006. 03. 16., cs – 00:37 )

egy olyan adalékot bányásztam ma ki guglin még hozzá, hogy aki hasonló jelenséget mondott, az azt mondta, hogy bizonyos router típusok nem dolgoznak jól együtt az ipv6-tal, csak ipv4 megy nekik. ez mintha megmagyarázná, hogy miért lesz ipv6-os címe a kártyának. legalábbis úgy néz ki...

viszont én még így sem tudom mit kezdjek vele, mert ehhez nem értek. valakinek ötlete? kissé uborkaszezonban vetettem fel a kérdést, erre már rájöttem :D

( pett1 | 2006. 03. 16., cs – 08:29 )

Nekünk otthon fix IP van beállítva a router mögött, én is nyomtam az Ubuntut, és ha elszállt a net, akkor nem lehetett a hálózatot újraindítani, azaz működésre bírni. Csak a reboot segített. Na ez az igazán idegesítő.

( Xterm v | 2006. 03. 16., cs – 10:06 )

ez ennyire általános jelenség?? mondjuk ehhez képest meg szinte semmi infót nem leltem a neten róla. sőt, tulképp az ipv6 dolgon kívül még csak azt se láttam, hogy lenne gond. ha pedig ilyen általános, akkor hogy nem panaszkodnak az emberek?

nekem különbne nem szokott olyan lenni, hogy nem jön vissza a net, vagy nem tudom kézzel se felkonfigni az ip-t. mert amint én kellek, onnantól megy. azonnal. (ma reggel pl. nem is volt gond...)

sajna ez lesz a megoldás addig, ameddig nem lesz jobb.. de ez olyan szánalmas, nem? továbbá azért ezt én elég komoly "bugnak" vélem, ha ez az egyszerű dolog nem működik üzembiztosan. azért egy ilyen rendszerben a hálózat felkonifigurálás sztem több mint alap dolog, nem ? :)

hát... gondolom nem olvastad, hogy más a breezyvel is járt így... az meg pont, hogy nem fejlesztői teszt verzió... azért ennyire nem egyszerű... különben meg teszt ide vagy oda, azért sztem ez nem olyan, hogy egy program x verziójában van-e bug. ha más nem, hát a dhcp-s netkonfig azért pl. a telepítéshez se utolsó. és a dhcp kliensekben a változások igazából össznépi változások, se nem ubuntu, se nem teszt verzió specifikusak. lehet pl. az ipv6 miatt. ez viszont nem elég ok arra, hogy ne is akarjam használni. sőt, a teszt verzióban pont az a lényeg, hogy megoldásokat keressünk, nem? ha szar, akkor lapítsunk? a büdös életben nem lesz javítva akkor. úgy meg minek kiadni a tesztverziót, hm?

őszintén szólva nem értem a reagodat...

Olvastam, hogy "nyomult" régebbivel is.
A program x-verziókban előforduló bugok meg bizony előfordulnak, még ha nem is látod szívesen őket, és ez jelentkezhet az adott napi upgrade-ba bekerült esetleges hibás dhclient, vagy networking configban is, amit jobb esetben egy fincsi bugreport után, vagy maguktól a következő nap javítanak.

"Üzembiztos" működést meg tényleg ne várj egy nem stabil rendszertől. Ha hibát találtál bugrepoltoj, és esetleg próbáld magad is javítani, akár csak otthoni felhasználásra is.

--
Intel Pentium 4 1.8GHz, 512 MB ram, 2.6.15.6-cvk-dell

értem. ezzel a céllal fordultam a fórumhoz is különben. való igaz, bármikor lehet bármiben kódhiba. simán. ami miatt én mégis furának találok egy ilyet az az, hogy egy intenzíven fejlesztett résznél ez jellemzőbb, mint egy talán kevésbé fejlesztett résznél (azért az xorg sztem pl. milliószor nagyobb kockázati tényező, mint egy dhcp kliens)

tehát ha a sok tapasztalat valamilyen irányban de elbillenti a mérleget, akkor fogok bugreportolni. bár... még nem tudom hirtelen, hogy vajon merre. dhcp csomagkok esetén tiszta lenne. egy network konfigoló script esetében viszont nem nagyon. erre van esetleg ötleted vagy tapasztalatod, hogy merre érdemes ilyenkor menni bugreport ügyben? nem várom el, hogy emilcímet, webcímet adj, bár megköszönöm, ha mégis. ;) ha viszont valaha bugreportoltál, akkor esetleg egy ilyen kérdésben inkább tudsz segíteni, mint aki pl. még sosem.

mivel úgy nézem nem egyedi az eset, ezért gondolom érdemes lehet. mit gondolsz?

( KoS | 2006. 03. 16., cs – 16:47 )

Nekem is megvolt ez a problema a stabil Ubuntunal, bugreportoltam is szepen a bugzillajukban, de megoldas nem jott ra.
Utana rauntam, es ez volt az egyik oka annak, hogy most mar Archlinux-ot hasznalok.
Egyebkent tapasztalataim szerint a kernelben ronthattak el valamit, mert a regi kernellel bootolva minden rendben volt (ugyanazt a rendszert bootoltam masik kernellel).

Hozzaadva:
Egyebkent a problema csak bizonyos halokartyakon jon elo (nekem integralt 3Com van) ezert nincs hagy hire szerintem.
Tapasztalataim szerint eleg keves embernel jott elo a problema.

hm... ez igen érdekes, viszont megmagyarázza a tényeket, hogy miért nincs javítva. akkor viszont kernelforgatásra fel :) avagy... helyből kicserélem valami másra és meglátom mi lesz. bár igazából csak egy dolog miatt nem sok kedvem van full custom kernelt forgatni. mégpedig a "specebb" vackaim miatt, a drivereit ne én keresgéljem már, meg nem nekem kell így túrkodni a driverekhez a modsorokat, ha valami miatt nem megy.

na jó, ez inkább kényelmesség :) lehet ki fogom próbálni azt, hogy csinálok egy kernelt az ő forrásukból. "full specet". mondjuk nem modulban lesz a driver a kártyához :)

alternatív megoldás: megy egy post az intel supportra is ;) ők már egyszer segítettek egy elég hajmeresztő bios bugjukban, ami állításuk szerint 3 helyen jött elő. ebből 1 az enyém :D

nem veszett el a remény :D

Hat, remelem sikerul.
Nekem nem volt kedvem kernelt forgatni, mert akkor minden uj kernelnel el kell jatszani, nem lehet sima upgrade. Meg amugy is erdekelt az Archlinux...
Egyebkent ha kernelt akarsz forgatni, akkor ajanlom hogy vanilla (azaz a kernel.org-rol letoltott) kernelt probalj meg, mert nem tudom hogy az Ubuntu mennyire patch-eli a kernelt, es lehet hogy o"k baltaztak el valamit es ez miatt nem megy a dolog.
Masreszt hasznald kiindulasi pontkent az Ubuntu kernel config fileja't (megtalalod a /boot-ban).
Ja es ne felejts ramdisk-et is csinalni, mert az nelkul nem indul el az Ubuntu (ahhoz hogy ugy is elinduljon, mar expertnek kellene lenned).
Szoval ha kernelt akarsz forgatin, akkor jarj utana az Ubuntu honlapon (valahol van egy leiras, hogy hogyan forgathatsz magadnak sajat kernelt).

azóta túrom a bugzillájukat. sok furcsa dhcp-s bugot találtam. illetve sok irányból volt körbejárva a kérdés. tisztára olyan, mintha a modul betöltődésekor még az init lassabban futna le, minthogy először használná. ez megmagyarázza, hogy miért nem konstans a problem, hanem miért random (elvégre a vinyó nem fix átfutási időkkel dolgozik, stb.).

úgy döntöttek két megoldás mellett voksolok. az egyik az interface file-ban egy pre-up string amivel "lefoglalja magát" a kártya drivere és csak később konfigolódik. ha nem hoz megoldást, akkor lehet kénytelen leszek kernelt forgatni (jogosak az aggájaid az upgrade miatt). én deb-et mindig saját kernellel hajtottam, soha nem volt bajom vele, ha már sikerült belőlni. engem a hotplug szerű vackok miatt vonz inkább a gyári kernel.

viszont ha már forgatok, akkor tuti nem modul lesz a kártya drivere ;)

jah, nem ramdrive kell, sztem te az initrd-re gondolsz. azt én rühellem, tehát ha forgatok, akkor a boothoz szükséges cuccok mind benne lesznek a kernelben. valamit valamiért...

ehhe :) igen, a definíció szerint az rd betűk a ram disket jelentik :) de a sima ram disk support az azért nem pont ugyan az ha jól emlékszem. ha valaki idetéved és ezt olvassa, akkor legyen teljes a kép benne :)

jelenleg ott tart a dolog, mint ahol az optimista öngyilkosjelölt is... "... eddig jó..." de majd meglátom, hogy vajon tartós javulást okoz-e. ha igen, akkor ide mindenképpen leírom, hátha más is profitál belőle. elvégre ezért van a fórum ;) /nem pedig csak azért, hogy "minek használod" beszólást postolhassunk :) /

( Xterm v | 2006. 03. 26., v – 10:10 )

Mivel megígértem, hogy a fejleményekről beszámolok, ezért jelzem, hogy a DHCP "bug" tünetkezelése megtörtént. Jelenleg egyszer sem fordul már elő az a probléma, hogy boot-oláskor nem venné fel az ip konfigját a dhcp szervertől. (azóta egyetlen update-et sem hajtottam végre, nehogy az bekavarjon, hogy valamit variálnak és az oldja meg a "háttérben")

a megoldás meglehetősen "buta" megoldás, de egyelőre 1 hét távlatából mondható az, hogy "működik". a kernel modul betöltésével lehet valami gond tehát, amiatt nem megy jól talán. ha viszont a dhcp konfigurációt elhúzom kicsit, akkor szépen működik. fórumokat túrva arra jutottam, hogy meglehet elég valami "késleltetés", de nem volt elég a "sleep jellegű" esemény. olyan kellett, ami a hálókártyát piszkálja. íme az, amit én csináltam az interface konfigjánál:

iface eth0 inet dhcp
pre-up /usr/sbin/ethtool -t eth0 online | egrep -iq '^link test.+[^0-9]0$'

ez csak egy kis "játék" a kártyával, de elegendőnek bizonyult. megkeresem az ubuntus brigádot is vele, hátha ők legalább megértik mi a gond, és milyen megoldás kell rá.

;)

most már csak rá kell fordulni arra a problémra, amit egy másik kolega jelzett a topikban, hogy neki le is tud potyogni a netről a gépe. én ott úgy vettem ki, hogy neki relatív "sokszor" csinálta. nekem eddig összesen alig volt 3 ilyen, tehát lehet más oka is. de tuti, hogy a kernel és a drivere a hibás sajnos...

közelebb fog vinni a megoldáshoz sztem, ha megfejtem mi a frászért csak 20 perces lease-ket kér az ubuntu a dhcp-től... ennek sztem baromi semmi értelme, haszna nincs... de kövezkezetesen 1400 mp-es időket kér. pl. a deb és a win is inkább napokban mérte és méri ma is. meglehet ennek van köze hozzá (pl. az egyik lease frissítésnél nem kapja meg a kért frissítést. nyilván próbálkozik újra, de azt ki a fene fogja kivárni?

egyelőre nem találom módját, miként tudnám ezt az időt elnyújtani... :(

( jonci | 2006. 03. 26., v – 11:11 )

mi van nálad a /etc/default/ifupdown fájlban?

debian/sarge, tudom, nem ubuntu, de gondoltam hátha nem ennyire eltérő a kettő
nekem spec mindegyik sora comment, de mindkét opció segíthet 


# Set to "yes" to turn on debugging messages in scripts
# DEBUG=""
 
# Time to wait for ifupdown to become ready at boot
# (Currently not used)
# IFUPDOWN_TIMEOUT=60

az hiszem nekem nem lesznek ezek jók. találtam hasonló filét, de ezzel egy bibim van. az, hogy az update agyoncsapja őket. illetve agyoncsaphatja. azt hiszem van mód a kikerülésre, de mindenképpen nekem kell innentől követnem, hogy mikor cserélik ki. az interface konfig file meg nem nagyon képezi update részét, mert az hálózatspecifikus, tehát helyi file. mintha a hostnév. sosem lesz update része :)

( Xterm v | 2006. 10. 02., h – 17:45 )

úgy gondoltam megpróbálom feléleszteni ezt a topikot, mert megoldás még mindig nincs és most újra jönnek azok a gondok, amik miatt a téma nyílt anno. a jelenség most is az, hogy boot, ipv6 kap címet (inet6 addr: fe80::207:e9ff:fe46:d3db/64 Scope:Link), de egyéb nuku. viszont ipv6 router a chellonál nincs, ergo forgalmazni nem tudok. van valakinek ötlete arra, hogy lehetne rávenni a dhcp scripteket ubuntun, hogy próbálkozzanak mégegyszer, ha elhullik a kérés?

bár... van párszor sajna az is, hogy már meglevő kapcsolatnál megdöglik, nem tudok forgalmazni tovább net restartig... ennek lehet oka esetleg, hogy rövid a dhcp lease ideje. (lehet ez a megoldás a másikra is??). ezt hogy tudom meghosszabbítani? nehogy már csak ezer mp-ekre kérje... (DHCPACK from 80.99.179.254 bound to a.b.c.d -- renewal in 1712 seconds.)

bármilyen hasznos tippet, ötletet elfogadok. a rendszer azóta is ugyan az, mint a topik indító írás alján jeleztem).