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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
