DHCP furcsaságok

Hálózatok egyéb

Hello!

A segítégeteket kérném:

Egy kollégiumbanban vagyok rendszergazda, az itt lakó hallgatók gépeinek DHCP-n osztunk IP-t. Azt a jelenséget tapasztalom, hogy az újabban behozott windows-os gépek (90%-ban laptopok) egyszerűen nem hajlandók DHCP-vel konfigurálni magukat, több percig próbákoznak, majd "kapcsolat nem jött létre, korlátozott stb.".

Mindeközben az én saját linuxos gépem, illetve az összes windowsos kollégiumi gép (dolgozók gépei, gépterem, stb.) amelyeknek én vagyok a "gazdája", mindenféle wireless, voip stb. eszköz a jelenséget nem produkálja.

Mesterségesen sem tudom előidézni a problémát, direkt telepítettem erre a célra egy gépre win-t, de azonnal, szépen ment a DHCP rajta.

Egy hallgatói gépnél volt olyan eset, szintén a "Win alól nem megy a DHCP" probléma volt, hogy próbáltam ubuntu live CD-vel, ott látszott, hogy a DHCPDISCOVER elmegy, de nem jön rá DHCPOFFER. Valószínűleg egyedi problémáról van szó, eléggé noname hálókártya volt benne, a chiptípust sem ismertem, valamint ezt szórta a logba: 

arpwatch: mac_address sent bad hardware format 0x0

Fix IP beállításával minden gép rendesen működik, a fent említett gép is megjavult így, a "bad hardware format" üzenetek szórását is befejezte ezután.

Találkoztatok már ilyesmivel?

(mindjárt megnézem az egyik ilyen problémás gépet live cd-vel, és jelentkezem...)

szerk: megnéztem, debian telepítő CD-vel, ugyanúgy rossz, mint Win alól. DHCPDISCOVER elmegy, de nem jön rá DHCPOFFER. Fix IP-vel visztont működik. A dhcpd konfig nem lehet rossz, mert ugyanabból az adatbázisból dolgozik, mint a gateway-en az iptables, tehát ha rossz a MAC address, akkor nem csak IP-t nem kap, de ki sem lát az internetre...

Hardveres hiba lenne? (Ez konkrétan egy ASUS F3M laptop volt.)

Petya

  • 4844 megtekintés

( furge | 2008. 01. 04., p – 11:03 )

nálunk most melóban a net előfizetőknél szintén tapasztalható, hogy nem tudnak ip-t lekérni. főleg vistás gépeknél jön elő ilyen. mondták a munkatársaim, hogy állítólag jött valami win frissítés és azóta tapasztalható ez

( Tyra3l | 2008. 01. 04., p – 12:47 )

dhcp pool meg veletlenul sem urult ki, ugye?
halozaton csak 1 dhcp szerver van?

Tyrael

( maniac | 2008. 01. 04., p – 13:23 )

Erdemes lenne megnezni, hogy nem fogytal-e ki az ip cimekbol. Nalunk volt mar ilyen, hogy kicsit tul sokra lett beallitva a lease time, es mikor mindne heten hoztak a kedves menedzserek a vilag minden szegletebol kulonbozo laptopokkal egyszer csak nem akartak ip-t kapni az ujabb notik.

( wildy | 2008. 01. 04., p – 13:24 )

Nezd meg a switch port beallitasait, pl. Cisco eszkozoknel port fast a neve. Ezek neha olyan "intelligensek", hogy a DHCP/PXE kliens mar reg timeout-ol, mire a portot bekapcsoljak...

( _Petya_ v | 2008. 01. 04., p – 14:29 )

Hello!

Egyben válaszolok mindre:

Tyra3l, maniac:

Static DHCP van, MAC address-t le kell adni, és csak az kap DHCP-n IP-t, aki leadta, és ugyanahoz a MAC-hez mindig ugyanaz az IP jár. Korábban nem volt DHCP, mindenkinek kézzel kellett beállítani. r=1 userek miatt lett DHCP, akik nem tudták beálltani kézzel az IP-t. Tehát pool kiürülés nem jón szóba. A sysogban sincs nyoma annak, hogy DHCP kérés jönne, tehát a DHCP szerver nem látja a DHCPDISCOVER-t ezek szerint.

wildy:

öszesen egy managelhető switch-ünk van, de ott sincs semmi korlátozás, pláne port kikapcsolás. Egy switch porton fél emeletnyi koliszoba van, olyan nincs, hogy ne legyen forgalom, és kikapcsoljon a port.. Az én gépem is ugyanazon a switch porton van, mint a problémásak, és ez mindig jó.

Petya

( redmedve | 2008. 01. 05., szo – 14:04 )

Ilyesmit én is tapasztalok, én épp Győrött, ahol ugyanez a rendszer, nem tudom te hol :)

Ha a mac címet átírom, akkor utána a laptopom w2k-val simán kap ipt, ha vissza akarom rakni az asztali gépemre, amiben nforce2-es lap van és xp-s, akkor minimum fél óráig nem kap ip-t.

Tavaly ilyen problémám nem volt.

( Mik v | 2008. 01. 05., szo – 16:10 )

ipconfig /release
ipconfig /renew
megvolt? Windows szereti ugyanazt a címet visszakérni amit korábban (valahol) kapott. És különösebben nem érdekli, hogy Te másikat adnál neki...

( _Petya_ v | 2008. 01. 09., sze – 22:08 )

Hello!

Boot-oltam az egyik problémás gépen nUbuntu-t, abban van Wireshark, és sniffeltem a DHCP csomagokat, ugyanazt látom, mint parancssorból: elmegy a DHCPDISCOVER, de nem jön rá DHCPOFFER.

Azért idelinlekem a sniff eredményét: http://molnarp.pastebin.com/m8363bf3

Megnéztem a szerveren is tshark-al (tethereal), ott is ugyanez, Discover-t látja, de Offer nem megy rá. Mindeközben a többi gépről simán megy, ahogy kell: discover, offer, request, ack.

szerk: a tshark-al nem sikerült teljes logot generálni, csak 1 sor/csomag-os kimenetet. Hogyan tudom rávanni, hogy olyat gerenáljon, mint amit fentebb linkeltem?

Petya

( _Petya_ v | 2008. 09. 09., k – 16:56 )

Sziasztok!

Felhoznám ezt a régi topicomat, ugyanis a problémát még mindig nem sikerült megoldani. A legtöbb gép, amit hoznak nekem, Vista-s, vagy XP SP3-as, ezeken kb 90%-ban nem működik a DHCP. Köztük olyanokon, amelyre a tulajdonos 100%-ra állítja, hogy otthoni hálózatban működött neki.

részlet a dhcpd.conf-ból: 


#szubnet ahova dhcp-t szolgaltatunk
subnet 1.2.3.0 netmask 255.255.255.0 {
}

#egy masik, ahova nem
subnet 5.6.7.0 netmask 255.255.255.0 {
}

# ez egy host, meg kb 200 ugyanilyen van, csak az xxx-el jeloltek valtoznak
host hostneve {
        hardware ethernet xx:xx:xx:xx:xx:xx;
        option broadcast-address 1.2.3.255;
        option routers 1.2.3.254;
        option subnet-mask 255.255.255.0;
        option domain-name "valami.domain.hu";
        option domain-name-servers 1.2.3.254, 1.2.10.16;
        fixed-address 1.2.3.xxx;
}

Van valakinek ötlete? Ti láttatok már ilyet?

update: biztosan nem switch hiba, mert a központi switch-re (ahol a DHCP szerver is van) dugott "problémás" kliensen is jelentkezik. Egyébként az illető szerver gateway és egyben DHCP-t is szolgáltat.

Petya

Azért nem működik, mivel az 1.2.3.xxx nem tartozhat az 5.6.7.0/24-be.

Valóban nem tartozik, de szó sincs arról, hogy oda tartozna. Az 5.6.7.0 subnetről nem jönnek DHCP kérések, azzal nem kell foglalkozni. Csak fel vannak sorolva az interface-ekhez rendelt subnetek (mindkettő üres, mert static DHCP van, nincs pool), majd alatta a hostok, fixed-address-el.

Tehát szerinted vegyem ki az 5.6.7.0 subnetet a dhcpd.conf-ból (és persze a /etc/default-ban lévő konfigfile-ból is az illető interface-t)?

Illetve ha ez így rossz, akkor a legtöbb gépen miért működik?

szerk:

módosítottam, így: 


#egy masik, ahova nem
subnet 5.6.7.0 netmask 255.255.255.0 {
}

#szubnet ahova dhcp-t szolgaltatunk
subnet 1.2.3.0 netmask 255.255.255.0 {


        # ez egy host, meg kb 200 ugyanilyen van, csak az xxx-el jeloltek valtoznak
        host hostneve {
                hardware ethernet xx:xx:xx:xx:xx:xx;
                option broadcast-address 1.2.3.255;
                option routers 1.2.3.254;
                option subnet-mask 255.255.255.0;
                option domain-name "valami.domain.hu";
                option domain-name-servers 1.2.3.254, 1.2.10.16;
                fixed-address 1.2.3.xxx;
        }

}

Az én linuxos gépemen, illetve több régi windows-oson tökéletes, az újakon rossz.

Petya

Én mondjuk csak azt szoktam benthagyni ahova osztok címeket. De ettől még mennie kellene...
Viszont egy számomra érdekesség:
mind a 200 host-hoz fel van sorolva az "option akármi"? Ha beteszed a subnet-be akkor csak a MAC címet és az IP címet kell a host-nál megadni...
Az intercafe-ek milyenek? Vlan? (eth0.1) Vagy virtual? (eth0:0) Vagy valami egyéb? Ezeknek az IP címe netmask-ja, network-je, broadcast-ja jól be van állítva?
Nálunk vlan-ok vannak a dhcp szerveren és eddig (kopp-kopp) nem volt ilyen gondunk. (Debian etch, DHCP 3.0.4-13)
pár érdekes google találat
link1
link2
link3

Hello!

Igen, az option-ok mindenhol ott vannak (script generálja a konfigot, adatbázisból). Akkor átrakom a subnet-be.

Az interface vlan, de nincs is baj vele, viszont most látom a logban, hogy: 

dhcpd: no free leases on subnet 1.2.3.0

Ez hogyan lehet, ha mindenki fix IP-t kap? (ja és mind a 200 IP ténylegesen használatban van, azokat generálja bele a script a file-ba, ami ki van adva valakinek)

Petya

( _Petya_ v | 2008. 09. 11., cs – 16:15 )

Sziasztok!

Működik minden, a dhcp3-ra váltás volt a megoldás.

Egyébként, lenne még egy kérdésem a DHCP kapcsán:

2 VLAN-om van, és van pár szerver, amelyeknek mindkét VLAN-ban van egy-egy lába (VLAN-t tudó hálókártyával). Ezért a hostnév, és a MAC address is megegyezik, viszont nyilván két külön szubnetben, két külön domainben vannak, ennek ellenére warningol rá a DHCP3. Mi ezzel a baj pontosan, miért nem lehet ilyet csinálni?

Petya

Lehet többre mennénk ha bemásolnád a warning üzenetet mert nekem így nem világos amit írtál...
DHCP3 el sem indul ha a configban két egyforma host deklaráció van. A {} között már lehet ugyanaz minden az IP cím kivételével. Én ezt így oldom meg:
[code]
host hostneve_1.2.3.4 {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 1.2.3.4;
}

host hostneve_1.1.1.1 {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 1.1.1.1;
}

Mik

"Van valakinek ötlete?"
Igen. Ez nem erre való, de természetesen be lehet állíttatni a host nevét is. Nézzük meg, mit ír erről a man!

man dhcpd.conf:
The host statement
  host hostname {
    [ parameters ]
    [ declarations ]
  }

hostname should be a name identifying the host. If a hostname option is not specified for the host, hostname is used.

man dhcp-options:
option host-name string;
This option specifies the name of the client. The name may or may not be qualified with the local domain name (it is preferable to use the domain-name option to specify the domain name). See RFC 1035 for character set restrictions. This option is only honored by dhclient-script(8) if the hostname for the client machine is not set.

Észrevétel: szervernek vagy switchnek véleményem szerint nem túlzottan célszerű DHCP-vel IP-t és egyéb adatokat kiosztani.

Azt írta, hogy már működik minden, kivéve azt, hogy ugyanazt a hostnevet szeretné kiosztani ugyanahhoz a MAC-hez. Itt csak az a helyzet, hogy mivel a host deklaráció azonosítójának muszáj egyedinek lennie, ilyenkor a fenti man idézet alapján a hostnevet a host-name opcióval célszerű kiadni.