Clients not requesting address

[Glenn Satchell]

On 09/01/10 23:06, Wolfgang Zweimueller wrote:
>
> Dear List!
>
> I have a weird situation where PXE-clients most of the time do not
> request an offered IP-address. Maybe one can give a hint where or how
> to search.
>
> My setup: we run a failover system on two RedHat server with 4.1.1 for
> a lot of /24 nets. Some of them are dynamic only and some are fixed
> addresses only. (I have never deleted the lease-file ;-)
>
> For PXE there is another server which offers the PXE-specific boot
> info. This is done via forwarder config on the router.
>
>
> Here's an example where a client gets an address at first attempt and
> after reboot it does not request the offer:
>
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:28 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPREQUEST for 192.168.102.152 (192.168.102.179) from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPACK on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPREQUEST for 192.168.102.152 (192.168.102.179) from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPACK on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPREQUEST for 192.168.102.152 (192.168.102.179) from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPACK on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPREQUEST for 192.168.102.152 (192.168.102.179) from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: DHCPACK on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:30 u1ru169 dhcpd: bind update on 192.168.11.49 from lkh rejected: incoming update is less critical than outgoing update
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:42 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:44 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:48 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:48 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:48 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:48 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:48 u1ru169 dhcpd: DHCPDISCOVER from 00:1e:0b:64:37:39 via eth0
> Sep  1 13:46:48 u1ru169 dhcpd: DHCPOFFER on 192.168.102.152 to 00:1e:0b:64:37:39 via eth0
>
>
>
> The corresponding config for this host is:
>
> ,----
> | subnet 192.168.102.0 netmask 255.255.255.0 {
> | pool {
> |         failover peer "lkh";
> |         range 192.168.102.0 192.168.102.0;
> |         option routers 192.168.102.242;
> |         option domain-name "kliniken.lks.local";
> |         option domain-search "lksdom21.lks.local", "kliniken.lks.local";
> |
> |         host C1SV119 {
> |                 hardware ethernet 00:1E:0B:64:37:39;
> |                 fixed-address 192.168.102.152;
> |                 option host-name "C1SV119";
> |         }
> | }
> | }
> `----
>
>
>
> Many thx in advance,
> Wolfgang

It may be that there is some missing dhcp-option in the offer which 
causes the client to ignore it. Try using tcpdump to look at the 
incoming dhcp packets and see what options are being requested.

In my dhcpd.conf I found I needed use something like this for HP 
Desktops to PXE boot correctly. The tricky bit was disabling multicast tftp:

# Option definitions for PXE
#option space PXE;
option space PXE code width 1 length width 1 hash size 3;
option PXE.mtftp-ip code 1 = ip-address;

# PXE boots for jumpstarting x86 boxes
class "PXE" {
   match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
   next-server drill.uniq.com.au;
   filename "pxegrub.I86PC.Solaris_10-1";
   # 10 minutes should be long enough for PXE
   max-lease-time 600;

   # don't use multicast tftp option
   vendor-option-space PXE;
   option PXE.mtftp-ip 0.0.0.0;
}



-- 
regards,
-glenn
--
Glenn Satchell                            |  Miss 9: What do you
Uniq Advances Pty Ltd, Sydney Australia   |  do at work Dad?
mailto:glenn.satchell at uniq.com.au         |  Miss 6: He just
http://www.uniq.com.au tel:0409-458-580   |  types random stuff.