net-install dhclient against named
hi
i just downloaded debian net-install, put it on a cd and installed it.
in the network is a named server "BIND 9.2.3" - a old one distributing
addresses since years to win, macs, linuxes, printers, accesspoints and so
on. a month ago i installed the brand new ubuntu on a laptop - works fine.
until now the only dhclient which does not work is ... debian.
the nameserver is logging ....
Dec 24 07:24:21 alexia dhcpd: DHCPDISCOVER from 00:0f:b5:8a:ac:f1 via eth1
Dec 24 07:24:21 alexia dhcpd: DHCPREQUEST for 192.168.69.1 (192.168.69.254)
from 00:0f:b5:8a:ac:f1 via eth1: wrong network.
Dec 24 07:24:21 alexia dhcpd: DHCPNAK on 192.168.69.1 to 00:0f:b5:8a:ac:f1
via eth1
Dec 24 07:24:21 alexia dhcpd: DHCPREQUEST for 192.168.69.1 (192.168.69.254)
from 00:0f:b5:8a:ac:f1 via eth1: wrong network.
Dec 24 07:24:21 alexia dhcpd: DHCPNAK on 192.168.69.1 to 00:0f:b5:8a:ac:f1
via eth1
Dec 24 07:24:22 alexia dhcpd: DHCPOFFER on 192.168.1.194 to
00:0f:b5:8a:ac:f1 via eth1
the server tell exactly the problem - DHCPNAK because asking for wrong
network. at the end the server is offering DHCPOFFER a address in his
network range.
debian and ubuntu have same installation package dhcp3 and behave else.
ubuntu accept the offered address 192.168.1.186 and debian is ignoring the
offered address, take his own 192.168.69.1. i was wondering the difference
and investigated the environment. stopped the ip interface on both machines
by calling ifdown. i than deleted the cache in /var/lib/dhcp3 and set the
dhclient.conf exactly the same. and started up the interfaces again by
calling ifup. i found the difference in the /sbin/dhclient-script:
make_resolv_conf() handling the $new_domain_name_servers in a other way.
debian set new_domain_name to <> and new_domain_name_servers to
<192.168.69.254>
ubuntu is using the information out of resov.conf. <oehlers> <192.168.1.51
212.40.0.10>
i have testet both installations on a dumb dlink accesspoint as well.
debian set new_domain_name to <> and new_domain_name_servers to
<192.168.76.1>
ubuntu is using the information out of resov.conf. <> <192.168.76.1>
switching back the ubuntu to the 192.168.1 network it runs into same problem
as debian until i deleted the cache and changed resolv.conf.
the negotiation continues afer the servers offer for his subnet. why?
Dec 24 12:29:55 alexia dhcpd: DHCPOFFER on 192.168.1.193 to
00:19:b9:7b:be:fd (OisConsultWS1) via eth1
Dec 24 12:29:55 alexia dhcpd: DHCPDISCOVER from 00:19:b9:7b:be:fd
(OisConsultWS1) via eth1
Dec 24 12:29:55 alexia dhcpd: DHCPOFFER on 192.168.1.193 to
00:19:b9:7b:be:fd (OisConsultWS1) via eth1
Dec 24 12:29:55 alexia dhcpd: DHCPREQUEST for 192.168.1.193 (192.168.1.6)
from 00:19:b9:7b:be:fd (OisConsultWS1) via eth1
Dec 24 12:29:55 alexia dhcpd: DHCPACK on 192.168.1.193 to 00:19:b9:7b:be:fd
(OisConsultWS1) via eth1
first broadcast after new installation is ....
Dec 24 07:24:21 alexia dhcpd: DHCPREQUEST for 192.168.69.1 (192.168.69.254)
from 00:0f:b5:8a:ac:f1 via eth1: wrong network.
why is the debian client asking for a address 192.168.69.1 from a nameserver
192.168.69.254? it never was on the net before?
what is wrong with the servers answer DHCPNAK when the client is asking a
addres for a other subnet?
why is the client "dhclient" ignoring the servers offer after a DNCPNAK?
why is debian first deleting resolv.conf and than tries to lookup for his
network 192.168.69 ?
is there any one else working in BIND 9.2.x environment, having same
problems?
thx for answer
juerg (=george)
Reply to: