Fórum Root.cz
Hlavní témata => Software => Téma založeno: Pali 14. 07. 2013, 20:43:21
-
Ahojte, mam problem s dhclientom. Ak uz bezi asi tak den a viac zacne do syslogu kazdych asi 10 sekund vypisovat tuto hlasku:
...
Jul 14 08:13:54 pc dhclient: DHCPREQUEST on eth0 to <IP> port 67
Jul 14 08:14:05 pc dhclient: DHCPREQUEST on eth0 to <IP> port 67
Jul 14 08:14:14 pc dhclient: DHCPREQUEST on eth0 to <IP> port 67
...
Ak si to nevsimnem, tak logy zacnu byt strasne velke a zacnu zrat miesto...
Siet ale funguje bez problemov a eth0 ma bez zmeny pridelenu poslednu IP adresu. Ak dhclient zabijem a spustim ho opat, tak ihned dostanem pridelenu ip adresu a vsetko funguje asi tak den/dva bez problemov.
Teda problem je podla vsetkeho v dhcliente, mam verziu isc-dhclient-4.2.2 z debian wheezy. Spusta ho ifup ako:
dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
Nejaky napad preco to dhclient kazdych 10 sekund robi, nedostane ziadnu odpoved a ked ho spustim nanovo tak dostane odpoved ihned? Nie je to nejaky znamy bug?
Co robit v tomto pripade? (Prestavovat syslog ci nastavit cron aby mi dhclienta restartoval raz za den je iba docasne riesenie)
-
Problem trva az dovtedy kym nevrpsi RENEW time a dhclient neposle REBIND na broadcast. Potom uz dhcp server obnovi IP adresu bez problemov. Preto sa snazim nastavit aby dhclient nerobil RENEW ale rovno REBIND, ktory funguje.
Snazil som sa napevno nastavit RENEW a REBIND casy na rovnake hodnoty ale dhclient to aj tak zignoruje a robi si veci po svojom.
Do dhclient.conf som pridal:
supersede dhcp-renewal-time = encode-int(36000, 32);
supersede dhcp-rebinding-time = encode-int(36000, 32);
A potom dhclient do lease file zapisal:
option dhcp-lease-time 86400;
option dhcp-renewal-time 36000;
option dhcp-rebinding-time 36000;
renew 0 2013/07/21 13:21:23;
rebind 0 2013/07/21 15:18:18;
expire 1 2013/07/22 05:18:18;
V case rebind lease file obnovil na:
option dhcp-lease-time 86400;
option dhcp-renewal-time 36000;
option dhcp-rebinding-time 36000;
renew 1 2013/07/22 00:48:09;
rebind 1 2013/07/22 01:18:28;
expire 1 2013/07/22 15:18:28;
Vyzera ze volby dhcp-renewal-time a dhcp-rebinding-time pochopil, ale cas pre renew nastavil zle. Testoval som to a renew cas nastavuje nejak nahodne cca o hodinu az dve skor ako rebind.
Ako sa potom da ten dhclient od isc nastavit aby rebind time cas sa rovnal renew time? Tu nahodnu odchylku robi naschaval? Fakt tomu nechapem.
-
Co je tím DHCP serverem. Není to v síti UPC?
Napadá mně následující možnost (se kterou jsem se setkal)
- tvůj klient na začátku dostane IP conifg od DHCP serveru normálně
- při renew se klient nesnaží posílat request na broadcast, ale přímo na IP adresu, odkud mu minule odpověděl DHCP server, přitom ale routa na tento server v routovací tabulce chybí
- při rebind nebo při úplném vypršení lease už dhcp klient pošle discover na broadcast a až tehdy mu server odpoví.
Podrobně bych si přečetl logy případně tam nechal běžet tcpdump pro podrobnější prozkoumání
-
ak som spravne diagnostikoval vsetky veci, tak mam nasledujuci problem:
Mam dva interfacy eth0 a eth1, oboje dostavaju ip adresu pomocou dhcp. Default route pouzivam od eth1. Problem je ze dhcp servery ktore prideluju adresy pre eth0 a eth1 maju asi zhodou okolnosti rovnaku ip adresu a teda z eth0 sa na ten spravny nedostanem. A to bude dovod preco renew pre eth0 nefunguje, ale rebind (ktory posiela packety na broadcast) ano.
Preto som sa snazil nastavit dhclient aby renew nepouzival ale rovno skocil do stavu rebind.
-
V jaky je to siti? Pred par lety jsem neco do ISC dopisoval a jestli se nepletu, tak po vyprseni 1/2 lease time se dhclient snazi prodlouzeni vypujcky IP adresy. Ta se ale z nejakeho duvodu neprovede.
- ISP ma "bordel" v siti
- ty mas bordel v routach
- DHCP server te odmitne, napr. proto, ze se identifikujes jinym jmenem a on te nenajde ve svych leases. Taky jsem videl moznost, ze klient v packetu uvadel, ze akceptuje odpovedi do max 256B zatimco on sam posilal request vetsi - to zase neproslo pres Cisco.
-
po vyprseni 1/2 lease time se dhclient snazi prodlouzeni vypujcky IP adresy.
Ako to vypnut?
Ta se ale z nejakeho duvodu neprovede.
Ak som vsetko spravne diagnostikoval, tak spravny dhcp server ani neviem zkontaktovat priamo na jeho ip adresu. Vid predchadzajuci prispevok.
-
po vyprseni 1/2 lease time se dhclient snazi prodlouzeni vypujcky IP adresy.
Ako to vypnut?
Nejspíš zásahem do kódu DHCP klienta, ale je to ošklivý hack. DHCP je standardizovaný protokol a jeho chování je pěkně popsané například tady: http://www.tcpipguide.com/free/t_DHCPLeaseRenewalandRebindingProcesses-2.htm
Ta se ale z nejakeho duvodu neprovede.
Ak som vsetko spravne diagnostikoval, tak spravny dhcp server ani neviem zkontaktovat priamo na jeho ip adresu. Vid predchadzajuci prispevok.
Pokud máte špatně nastavenou síť tak by řešením mělo být správně nastavit síť a ne hledat různé jiné hacky které mohou mít všelijaké neblahé důsledky!
-
Ja si myslim, ze to nie je spatne nastavena siet. Proste som pripojeny do dvoch (takmer nezavislych) sieti a dhcp sa pouziva v oboch sietach na nastavenie ip adries. Pridal som este staticke routy ktore mi nastavia ktore rozsahy adries chcem z ktorej siete. No a problem je ten, ze dhcp servery maju v oboch sietach rovnaku ip adresu. A teda sposob akym je dhclient defaultne nastaveny je nefunkcny pre tuto situaciu. Hackovaniu zdrojakov dhclienta som sa prave chcel vyhnut a myslel som si ze to co pisu v dokumentacii o "supersede dhcp-renewal-time" funguje tak ako je to tam napisane a ne ze si dhclient bude robit aj tak po svojom.
-
No a problem je ten, ze dhcp servery maju v oboch sietach rovnaku ip adresu.
Stejná IP adresa v různých sítích? Jak už jsem napsal: pokud máte špatně nastavenou síť tak by řešením mělo být správně nastavit síť.
-
Pane Někdo, můžete mi prosím vysvětlit proč ve dvou oddělených sítích nemohou být stejné IP? Jsem skutečně zvědav. ::)
Pravidlo ve FW máte na i na established a related? Nedávno jsem nemohl najít chybu a byla to taková pitomost, že už bylo spojení navázané, takže se přestalo pravidlo aplikovat. U DHCP by to měl být podle mého zcela nový request, ale kdo ví...
-
Do ty tvoji site bych teda chtel bejt pripojenej... ::) ;D
-
Pane Někdo, můžete mi prosím vysvětlit proč ve dvou oddělených sítích nemohou být stejné IP? Jsem skutečně zvědav. ::)
No je to uplne normalne, ze dhcp server bezi na 192.168.1.1. Nemam pocit zeby to niekto zakazal. Ip adries je konecne vela, specialne aj tych privatnych. A v dnesnom svete je urcite porovnatelne vela (ak nie viacej) dhcp serverov ako privatnych ipv4 adries. Takze aj z holubnikoveho principu vyplyva, ze je mozne aby dva dhcp servery mali rovnaku ip adresu :-)
Pravidlo ve FW máte na i na established a related? Nedávno jsem nemohl najít chybu a byla to taková pitomost, že už bylo spojení navázané, takže se přestalo pravidlo aplikovat. U DHCP by to měl být podle mého zcela nový request, ale kdo ví...
iptables mam spravne. Asi si nepochopil v com je problem. Tak to skusim viac rozpisat.
Ak dhcp klient robi renew, tak posiela unicast udp packet na adresu dhcp servera. Teda packet prejde routovaciou tabulkou a (v tomto pripade) pouzije default route. Avsak ak oba dhcp servery maju rovnaku ip adresu, tak nie je mozne routovaciu tabulku nastavit tak, aby dhcp klient pre eth0 isiel inou cestou ako dhcp klient pre eth1. A teda v tomto pripade dhcp klient posiela renew dhcp serveru do druhej siete a nema sancu skontaktovat spravny dhcp server cez unicast. Samozrejme ten druhy dhcp server ho uplne ignoruje, kedze mu nic nepridelil.
Ak dhcp klinet robi rebind, tak posiela broadcast udp packet na konkretny interface na 255.255.255.255. Teda vtedy sa packet dostane cez spravny interface na spravny dhcp server a klient dostane hned odpoved.
Nech sa budem snazit akokolvek, tak renew bude fungovat vzdy iba pre jeden interface (ten ktory bude mat v routovacej tabulke 192.168.1.1).
-
Rozumiem tomu dobre?
Chces, aby na eth0 aj eth1 sa nastavovala adresa cez DHCP, a vies, ze na obidvoch interfaceoch je DHCP server s IP adresou 192.168.1.1, a aj tebe, prideli nieco z rozsahu 192.168.1.2-192.168.1.254
Nic v zlom, ale toto fakt nie je asi moc podporovane(normalne, rozumne) nakonfigurovana siet.
Dajme tomu, ze chces komunikovat s 192.168.1.42
A s ktorym????
Ako si vobec predstavujes, zeby to malo fungovat?
-
Rozumiem tomu dobre?
Chces, aby na eth0 aj eth1 sa nastavovala adresa cez DHCP, a vies, ze na obidvoch interfaceoch je DHCP server s IP adresou 192.168.1.1, a aj tebe, prideli nieco z rozsahu 192.168.1.2-192.168.1.254
Nie nastastie mi prideluje adresy z roznych blokov. Takze dole uvedeny pripad nenastava. Jediny problem je prave komunikacia s dhcp serverom.
Nic v zlom, ale toto fakt nie je asi moc podporovane(normalne, rozumne) nakonfigurovana siet.
Dajme tomu, ze chces komunikovat s 192.168.1.42
A s ktorym????
Ako si vobec predstavujes, zeby to malo fungovat?
-
Nic v zlom, ale toto fakt nie je asi moc podporovane(normalne, rozumne) nakonfigurovana siet.
Dajme tomu, ze chces komunikovat s 192.168.1.42
A s ktorym????
Ako si vobec predstavujes, zeby to malo fungovat?
Aj keby, je to regulerne a stale sa to da nakonfigurovat a dokonca rovnako ako vsetko ostatne routovanie:
$ ip route add 192.168.1.42 dev eth0
Ale toto nie je moj pripad :-)
-
Rozumiem tomu dobre?
Chces, aby na eth0 aj eth1 sa nastavovala adresa cez DHCP, a vies, ze na obidvoch interfaceoch je DHCP server s IP adresou 192.168.1.1, a aj tebe, prideli nieco z rozsahu 192.168.1.2-192.168.1.254
Nie nastastie mi prideluje adresy z roznych blokov. Takze dole uvedeny pripad nenastava. Jediny problem je prave komunikacia s dhcp serverom.
Jedinym problemem je spis vase dosti zvlastni konfigurace site s dvema sitovkama na ruznych sitich, ale se stejnou adresou site. Nevim, proc trvate na tom, ze je bug v dhclientovi.
-
Jedinym problemem je spis vase dosti zvlastni konfigurace site s dvema sitovkama na ruznych sitich, ale se stejnou adresou site. Nevim, proc trvate na tom, ze je bug v dhclientovi.
Nemam ani rovnaku adresu siete, jedine dhcp servery maju rovnaku adresu.
A ci je to bug dhclienta, to neviem. Snazil som sa ho nakonfigurovat tak, aby renew a rebind cas boli rovnake. Ale toto odmietol bez akejkolvek debug hlasky a tvaril sa, ze je vsetko v hohode. Preto si myslim ze je to bug bud v dokumentacii a volby
supersede dhcp-renewal-time = encode-int(36000, 32);
supersede dhcp-rebinding-time = encode-int(36000, 32);
su tam iba na paradu, alebo je to bug v programe, pretoze nedodrzuje to co mu clovek zada do konfiguraku.
Ale aby sme sa poholi dalej, da sa ten dhclient tak nastavit (bez opatchovavania)?
-
OK, nie si teda jediny....
Ako naznacuju odpovede na
http://serverfault.com/questions/351179/why-is-dhclient-issuing-a-unicast-dhcprequest-every-15-seconds-instead-of-at-t1
tak asi ide ozaj o problemy s Providerom.(ako sa aj pytal Dalimil)
Ten prvy pise, ze jeho provider neodpoveda na unicast DHCP requesty, a preto si pridal takéto NATovacie pravidlo:
iptables -t nat -A OUTPUT -d 10.0.0.0/255.0.0.0 -o eth1 -p udp -m udp --dport 67 -j DNAT --to-destination 255.255.255.255
takze ty skus
iptables -t nat -A OUTPUT -d 192.168.1.1/255.0.0.0 -o eth0 -p udp -m udp --dport 67 -j DNAT --to-destination 255.255.255.255
a hádam to pomôže.
Druhé, elegantnejšie riešenie, je v zodpovedajúcom konfiguráku napísať
interface "eth0" {
supersede dhcp-server-identifier 255.255.255.255;
}
Dúfam, že to vyrieši Tvoj problém... Ale je fakt divné, že Ti to začne blbnúť až po nejakom čase. Tak možno toto nebol ten problém :-)
-
OK, nie si teda jediny....
Ako naznacuju odpovede na
http://serverfault.com/questions/351179/why-is-dhclient-issuing-a-unicast-dhcprequest-every-15-seconds-instead-of-at-t1
tak asi ide ozaj o problemy s Providerom.(ako sa aj pytal Dalimil)
Ten prvy pise, ze jeho provider neodpoveda na unicast DHCP requesty, a preto si pridal takéto NATovacie pravidlo:
iptables -t nat -A OUTPUT -d 10.0.0.0/255.0.0.0 -o eth1 -p udp -m udp --dport 67 -j DNAT --to-destination 255.255.255.255
takze ty skus
iptables -t nat -A OUTPUT -d 192.168.1.1/255.0.0.0 -o eth0 -p udp -m udp --dport 67 -j DNAT --to-destination 255.255.255.255
a hádam to pomôže.
Toto zial nepomoze. Ja neviem matchnut packet od konkretneho procesu. Precitaj si cely popis problemu:
http://forum.root.cz/index.php?topic=6896.msg68337#msg68337
v OUTPUT sekcii uz je priradene odchadzajuce interface a DNAT iba zmeni cielovu adresu na broadcast pre interface eth0. Trebalo by pravidlo ktore pre dhclinet co bezi na eth0 posielal poziadavky na eth0 a dhclient co bezi na eth1 by posielal poziadavky na eth1. Ale ked dhclient posle unicast udp packet, ten prejde routovaciou tabulkou a kernel mu vyberie nejaku routu (v mojom pripade defaultnu) a aj odchadzajuci interface. Teda interface pre defaultnu routu. A ten je pre kazdy proces rovnaky... Do toho nevie vstupit ani iptables a ani samotny proces. (Alebo sa mylim a ide to nejakym spinavym trikom?)
Druhé, elegantnejšie riešenie, je v zodpovedajúcom konfiguráku napísať
interface "eth0" {
supersede dhcp-server-identifier 255.255.255.255;
}
Dúfam, že to vyrieši Tvoj problém... Ale je fakt divné, že Ti to začne blbnúť až po nejakom čase. Tak možno toto nebol ten problém :-)
Zacne to naozaj blbnut az po nejakom case. A nie nejakom, ale presne vtedy ked nastane renew time.
Ale idem vyskusat "supersede dhcp-server-identifier 255.255.255.255". Snad dhclient pochopi ze tato adresa je broadcast a ze packet musi odist na vseobecny broadcast daneho interfacu...
-
Super, tak vyzera ze dhclient volbu dhcp-server-identifier pochopil spravne a udp packety posiela naozaj na vseobecny broadcast daneho interface. Dik moc.
-
Tak po dni potvrdzujem, ze volba "supersede dhcp-server-identifier 255.255.255.255;" naozaj bez problemov funguje.