Dotaz: Klient nepotvrdi prijeti DHCPACK od DHCP3 serveru

[JetCat]

Dobry den,

mam uz nejaky ten rok router s Debianem (nyni 2.4.31), kde pouzivam pro pridelovani IP adres DHCP3 server podle MAC adres. Najednou se mi zacalo dit to, ze nekteri klienti neobdrzi IP adresu ackoliv ji DHCP3 server nabizi.

V logu je videt, ze probehne objeveni MAC adresy klienta (DHCPDISCOVER) a pote server nabizi spravnou IP adresu klientovi podle konfigu (DHCPOFFER). U vetsiny klientu pak je videt v logu potvrzeni prideleni (DHCPACK), u nekterych ale nikoliv a klient IP adresu neobdrzi. I kdyz vymenim zarizeni za jine (zmeni se MAC adresa), tak klient IP adresu neobdrzi. Kdyz zmenim IP adresu, tak ji stejne klient neobdrzi. V soucasne dobe ma konfig kolem 750 zaznamu a pouzivam shared-networks. Zkousel jsem i mazat ARP zaznam jestli neni problem v tomhle a nainstaloval jsem i arpd protoze jsem cetl na diskuzich, ze by mohl byt problem v omezene velikosti ARP tabulky.

Nesetkal jste se prosim nekdo s timto problemem ?

Predem diky za jakekoliv nakopnuti...

Jet

Odpovědi

[petr_p]

C: DHCPDISCOVER S: DHCPOFFER C: DHCPREQ S: DHCPACK

Podivejte se, co vam tece siti. Dorazi vsechny zpravy az na server / klienta? O DHCPREQ, ktery by si mel klient pozadat o konkretni IP, nic nepisete.

[JetCat]

Dobrý den, ano, u většiny klientů proběhne vše OK. Např.:
Dec 5 23:13:08 inetgw dhcpd: DHCPDISCOVER from 00:80:48:2b:79:de via eth1
Dec 5 23:13:08 inetgw dhcpd: DHCPOFFER on 10.0.106.30 to 00:80:48:2b:79:de via eth1
Dec 5 23:13:08 inetgw dhcpd: DHCPREQUEST for 10.0.106.30 (10.0.111.1) from 00:80:48:2b:79:de via eth1
Dec 5 23:13:08 inetgw dhcpd: DHCPACK on 10.0.106.30 to 00:80:48:2b:79:de via eth1
Ale u některých klientů jen první dva řádky... Nemůže to být rozsáhlostí sítě ? Nemůže to být nějakým parametrem jako time-to-live , že by se měl nějak prodloužit, já fakt nevím, nic mi nenapadá... Konzultoval jsem to s kamarádem, co má taky rozsáhlejší síť v jiném městě a ten mi řekl, že narazil na stejný problém a nevyřešil ho, musel začít používat statické IP. Jet

[JetCat]

Ještě jsem našel DHCPDUMP, což je utilitka, která spolupracuje s TCPDUMPem a ukáže podrobnosti ....

Takže ukázka neúspěšné komunikace DHCP serveru, při které již nedojde k DHCPREQUEST a DHCPAK.

---------------------------------------------------------------------------
  TIME: 23:57:38.546137
    IP: 0.0.0.0.68 (00:4f:62:03:9f:e7) > 255.255.255.255.67 (ff:ff:ff:ff:ff:ff,)
    OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 15c28642
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:0e:2e:53:56:12:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         1 (DHCPDISCOVER)
OPTION:  61 (  7) Client-identifier         01:00:0e:2e:53:56:12
OPTION:  60 ( 15) Vendor class identifier   udhcp 0.9.9-pre
OPTION:  55 (  6) Parameter Request List      1 (Subnet mask)
                                              3 (Routers)
                                              6 (DNS server)
                                             12 (Host name)
                                             15 (Domainname)
                                             28 (Broadcast address)
                                            
---------------------------------------------------------------------------
  TIME: 23:57:38.546821
    IP: 10.0.111.1.67 (4c:00:10:13:24:9b) > 10.0.103.68.68 (00:0e:2e:53:56:12,)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 15c28642
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.0.103.68
SIADDR: 10.0.103.1
GIADDR: 0.0.0.0
CHADDR: 00:0e:2e:53:56:12:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier         10.0.111.1
OPTION:  51 (  4) IP address leasetime      604800 (7d)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   10.0.103.1
OPTION:   6 (  8) DNS server                10.0.111.1,213.180.33.225
OPTION:  15 ( 11) Domainname                slansko.net
OPTION:  28 (  4) Broadcast address         10.0.103.255
--------------------------------------------------------------------------- 

Jet

[petr_p]

    IP: 0.0.0.0.68 (00:4f:62:03:9f:e7) > 255.255.255.255.67 (ff:ff:ff:ff:ff:ff,)
    OP: 1 (BOOTPREQUEST)

    IP: 10.0.111.1.67 (4c:00:10:13:24:9b) > 10.0.103.68.68 (00:0e:2e:53:56:12,)
    OP: 2 (BOOTPREPLY)

Tady je chyba. Odpoved musi jit na stejnou MAC adresu, z ktere prisel dotaz.

[yaplik]

no, hele, u tý špatný požadavek neposílá klient, ale dhcp relay, která ovšem nenastaví GIADDR a DHCP server si poté myslí, že je hnedka na segmentu s daným klientem a pak DHCPOFFER posle do místniho segmentu místo zpátky na dhcp relay tzn. špatně nastavená dhcp relay

horší je to, že něco jako dhcp relay tam nemá vůbec být, alespoň podle toho jak popisujes svoji síťovou topologii, takže bych to viděl na nějakej špatně nakonfigurovanej router (wifiap apod), kterej dělá problémy

btw. 1000x HW -> reknem tak 200x widle -> 200x kazdych 30s broadcast widlackyho sdileni -> 7x za sekundu broadcastovej paket, kterej na malou chvilicku paralizuje celou sit z dusledku jedne kolizni domeny pro broadcast, strašnej nářez

btw. MAC ma 6b + číslo portu 1b + 1b na zarovnání do 8b -> 8kb/8b=1024 stanic....

[petr_p]

Pokud byste mel sit hodne velkou s nekvalitnim vedenim pres hodne switchu, tak samozrejme muzete zaznamenat zvysenou ztratovost ramcu (pravdepodobnost bezchybneho prenosu klesa exponenciealne). Ale klient by mel po timeoutu poslat dotaz znovu.

Pisete, ze mate kolem 700 klientu na 1 server. Mam zkusenosti, ze dhcpd od ISC ma omezenou pamet na pool. Napr. Beckovou sit uz nepojme (16 bitu). Ale na to si uz stezuje pri spusteni. Taky se podivejte, jak mate velky lease soubor (nema vic jak 2 GiB?).

Pokud je jinak vse v poradku, asi bych se byt vami zacal divat po zdrojacich a po mailling listu venovanemu vasemu dhcpcd demonovi.

[JetCat]

a když už jsem v tom, tak zde je ukázka komunikace, která proběhne v pořádku s jiným klientem:

---------------------------------------------------------------------------
  TIME: 00:08:41.745363
    IP: 0.0.0.0.68 (00:10:c6:35:33:81) > 255.255.255.255.67 (ff:ff:ff:ff:ff:ff,)
    OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 99538827
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:10:c6:35:33:81:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         1 (DHCPDISCOVER)
OPTION:  61 (  7) Client-identifier         01:00:10:c6:35:33:81
OPTION:  12 (  7) Host name                 Dekonta
OPTION:  55 (  6) Parameter Request List      1 (Subnet mask)
                                              3 (Routers)
                                             15 (Domainname)
                                              6 (DNS server)
                                             43 (Vendor specific info)
                                             77 (User-class Identification)
                                            
---------------------------------------------------------------------------
  TIME: 00:08:41.745667
    IP: 10.0.111.1.67 (4c:00:10:13:24:9b) > 10.0.103.11.68 (00:10:c6:35:33:81,)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 99538827
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.0.103.11
SIADDR: 10.0.103.1
GIADDR: 0.0.0.0
CHADDR: 00:10:c6:35:33:81:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier         10.0.111.1
OPTION:  51 (  4) IP address leasetime      604800 (7d)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   10.0.103.1
OPTION:  15 ( 11) Domainname                slansko.net
OPTION:   6 (  8) DNS server                10.0.111.1,213.180.33.225
---------------------------------------------------------------------------
  TIME: 00:08:41.767238
    IP: 0.0.0.0.68 (00:10:c6:35:33:81) > 255.255.255.255.67 (ff:ff:ff:ff:ff:ff,)
    OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 99538827
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:10:c6:35:33:81:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         3 (DHCPREQUEST)
OPTION:  54 (  4) Server identifier         10.0.111.1
OPTION:  50 (  4) Request IP address        10.0.103.11
OPTION:  61 (  7) Client-identifier         01:00:10:c6:35:33:81
OPTION:  12 (  7) Host name                 Dekonta
OPTION:  55 (  6) Parameter Request List      1 (Subnet mask)
                                              3 (Routers)
                                             15 (Domainname)
                                              6 (DNS server)
                                             43 (Vendor specific info)
                                             77 (User-class Identification)
                                            
---------------------------------------------------------------------------
  TIME: 00:08:41.767632
    IP: 10.0.111.1.67 (4c:00:10:13:24:9b) > 10.0.103.11.68 (00:10:c6:35:33:81,)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 99538827
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.0.103.11
SIADDR: 10.0.103.1
GIADDR: 0.0.0.0
CHADDR: 00:10:c6:35:33:81:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
OPTION:  54 (  4) Server identifier         10.0.111.1
OPTION:  51 (  4) IP address leasetime      604800 (7d)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   10.0.103.1
OPTION:  15 ( 11) Domainname                slansko.net
OPTION:   6 (  8) DNS server                10.0.111.1,213.180.33.225
---------------------------------------------------------------------------

Jet

[Krystl]

Tak doma mam ten samy problem (nebo mozna podobny).
Kdyz hodim tcpdump na ten interface, tak vidim, ze klient pozadal dhcp o ipcku, ale server uz neodpovi. V logi serveru je ze obdrzel zadost o ip, ze nabizi ip a tot vse, jakoby tu nabidku neodeslal. Cas od casu se to na chvili udobri a funguje jak ma.
Zkousel jsem ruzne preinstalovavat, konfigurovat dhcp3-server, ale nic nepomohlo.

[JetCat]

Zdravim,

takze jsem nakonec zjistil nasledujici:

Problem s obdrzenim IP adresy od DHCP3 serveru maji zpravidla jen Ovislinky WL1120AP ve kterych je firmware BusyBox od Lukice + dopsane scripty pro udhcpc. Mame jich v siti pres 200 a delaji to jen nektere (asi 10 ks). Ma to ale nejakou souvislost i s ARP, protoze pokud na hlavnim routeru (ktery je i DHCP3 serverem) pridam staticky ARP zaznam pro IP adresu, tak za chvili ten Ovislink tu IP adresu obdrzi a z vysilace (APcko ZCOM s CPE firmwarem) si na nej pingnu - z hlavniho routeru ale nikoliv. Pritom je na stejnem vysilaci treba dalsich 5 Ovislinku ze stejneho rozsahu, s totoznym firmwarem a ty mi funguji OK.

Cela sit ma zhruba 1000 hardwarovych zarizeni, schvalne mam vsude switche s 8kb cache pro MAC adresy (8mi portove Edimaxy ES-3108P) kvuli velikosti, tak to by snad melo stacit.

Nekde ale musi byt zadrhel, protoze kdyz z APcka si na klienta pingnu a z hlavniho routeru ktery je za dvema mosty (tedy i za dvema switchi) ne, tak to je divoke. Dival jsem se i na defaultni nastaveni TTL a to je 64, nepomohla zadna zmena, ani smerem dolu, ani nahoru.

Jinak soubor /var/lib/dhcp3/dhcpd.leases je az na uvodni zakomentovane radky prazdny...

Samozrejme, ze asi jedinym spravnym resenim by bylo rozdelit sit pomoci routeru na kterych by bezel DHCP Relay, ale ted to predelavat by asi byla sebevrazda.

Jet

[Stanislav Petr]

Pokud vim, tak u original fw pro OvisLink je potreba nastavit adresu DHCP serveru, aby predaval spravne mac adresu. U tohodle fw by tomohlo bejt podobny.

[JetCat]

Zdravim,

u original fw se nastavuje DHCP Relay, coz umoznuje zarizenim pripojenym za Ovislinkem v rezimu Client obdrzet korektne IP adresu od DHCP serveru.

Ale jeste jedna vec, kdyz se podivam na pocet ARP zaznamu na hlavnim routeru v souboru /proc/net/arp , tak jich je jen 420 a to je malo. Nevim, zda to tak ma byt ci ne, pouzivam ARPD server a k tomu moc dokumentace neni :( jen ze pro spravnou funkci musi byt podpora NETLINKu a ARP Daemona v kernelu, to mam spravne.

Jet

[bd]

Zdravim, resili jsme stejny problem. Jeste to nemame dost dlouho testovane, treba se jeste stejne chyby projevi ale po nahrazeni nekterych Ovislinku WL1120AP novejsimi verzemi WL 5460AP, se problemy s DHCP prestaly objevovat. Az bude moznost to poradne zatizit, teprve se uvidi, ale prvni testy dopadly dobre. Tyhle novejsi verzi umi 802.11bg a maji take vic pameti.

[JetCat]

Zdravím,

u nás to dělalo jen pár kousků, nahradili jsme je novými šikovnými routery WH-2204A (výrobce údajně BlueCom, dodává je Aircom, www.wifihw.cz nebo i4shop.net pod podobným označením).

Jinak vy máte nějaký linuxový firmware pro WL5460AP ?? Vím že na něčem pracovali Poláci ale výsledek jsem ještě neviděl.

Ještě poznámka k DHCP Relay u Ovislinků. Zkusil jsem nastavit DHCP Relay u fw 1.03H a výsledkem bylo totální zahlcení spojů. Máme síť z transparentních bridgů, takže nalezení nějakého zařízení mělo za následek "bonzování" všech Ovisů :) Takovej mazec jsem ještě neviděl :) Musel jsem to všude povypínat.

Jet

[bd]

V tech, co mame, je podle logu BusyBox v1.00-pre8, kernel 2.4.18, tak nevim

[JetCat]

Ahoj,

no tak to je super. Můžeš mi prosím dát link ke stažení toho firmware nebo je to placená verze APPro ? Já bych si totiž pravděpodobně do toho stejně ještě dělal nějaké dodělávky :)

Jet

[mobidick]

Resim stejny problem, zatim neuspesne, problem zacal z niceho nic, po cca 3 letech provzu serveru.

[Jiří (BoodOk) Kadeřávek]

Pokud se jedna o problem po upgrade DHCP (Sarge->Etch), pak jsem podobny problem zazil pri ignorovani hlaseni debconfu, ze musim pridat do dhcpd.conf direktivu next-server.

[JetCat]

Zdravím,

next-server direktivu používám, to jsem také prověřoval...

Jet

[oron]

mam podobny problem ...
zapojene to ma asi takto:
pc -- radio bridge -- ap -- radio -- radio -- dhcp server

a presne mi to v logu dava iba

dhcpd: DHCPDISCOVER from 30:00:95:09:62:56 via 10.1.5.254
dhcpd: DHCPOFFER on 10.1.5.198 to 30:00:95:09:62:56 via 10.1.5.254

a tu sa mi to nezdalo - posiela ponuku cez ip 10.1.5.254
pre mac 30:00:95:09:62:56 co je mac eth na pc,
ale na AP som v arp table pod mac radio bridge a nie
mac na pc. niektore radia v klient mode nevedia prenasat mac adresy
a preto som na AP s mac radia.

na mojom radiu sa da nastavit klone mac adress
(moje radio bridge vie preniest iba jednu mac adresu)

ak som nastavil to clone mac - teda na AP bola v arp table
pre moju IP mac eth na pc a nie radia - tak sa to rozbehlo ...

neviem, mozno je to aj vas pripad ...