Dell iDRAC ignores dhcp offer

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure iDRAC as DHCP client
2. staticDHCP offer ip address but iDRAC ignores it
3.

What is the expected output? What do you see instead?
ISC-dhcp server and dhcpserver in Force10 switch works - dhcpdump shows:

  TIME: 2013-06-18 15:01:53.016
    IP: 10.20.0.23 (0:1:e8:d7:85:8e) > 10.20.0.253 (e0:db:55:20:8c:72)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 1
   XID: 4b872265
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.20.0.253
SIADDR: 10.20.0.23
GIADDR: 10.20.0.23
CHADDR: e0:db:55:20:8c:72: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.20.0.23
OPTION:  51 (  4) IP address leasetime      775923134 (1282w6d14h12m14s)
OPTION:   1 (  4) Subnet mask               255.255.255.0

The staticDHCP DHCPOFFER looks like this:

  TIME: 2013-06-18 15:01:29.311
    IP: 10.20.0.25 (90:b1:1c:49:dd:bc) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 83e0d837
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.20.0.43
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: e0:db:55:20:8c:72:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:  51 (  4) IP address leasetime      31536000 (52w24h)
OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier         10.20.0.25

What version of the product are you using? On what operating system?
Debian wheezy, tried with staticDHCPD-1.6.4 and 2.0.0-beta-2

Please provide any additional information below.
The only difference I see is that staticDHCPd responds to ff:ff:ff:ff:ff:ff 
instead of the client mac address ?

Original issue reported on code.google.com by kegef...@gmail.com on 18 Jun 2013 at 2:30

[GoogleCodeExporter]

That did the trick. 

2013-09-13 03:48:23,279 : INFO : DISCOVER from 00:25:90:85:00:e1
2013-09-13 03:48:23,286 : INFO : OFFER sent at 00:25:90:85:00:e1 for 
192.168.11.51 via 192.168.11.51:68 [311 bytes]
2013-09-13 03:48:23,360 : INFO : REQUEST:SELECTING from 00:25:90:85:00:e1 for 
192.168.11.51
2013-09-13 03:48:23,367 : INFO : ACK sent at 00:25:90:85:00:e1 for 
192.168.11.51 via 192.168.11.51:68 [311 bytes]

I'll continue testing over the next couple of days but so far looks good. 

THANKS!

Ken

Original comment by bhms.rob...@gmail.com on 13 Sep 2013 at 3:52

[GoogleCodeExporter]

No, thank you for all of your patience and for helping to clarify and test this.

Do you have any objection to being credited for your help?

I never thought I'd be handling kernel-level compatibility issues through 
Python, so the research and learning process was nothing but fun for me.

I'll get this out as beta8 tomorrow, then start working through the 
documentation a module or two per night to finally get an RC ready.

Original comment by red.hamsterx on 13 Sep 2013 at 3:58

[GoogleCodeExporter]

It was fun for me as well.  You can give me a small font amount of credit under 
yours.  I'll continue to bang on it over the weekend and I might even have 
access to a Dell PowerEdge that I could verify it against the IDRAC. 

Thanks again,
Ken

Original comment by bhms.rob...@gmail.com on 13 Sep 2013 at 4:13

[GoogleCodeExporter]

Testing went well yesterday and through the night.  I haven't seen anything 
unusual in my environment although it is a fairly controlled network.   I 
should have access to a Dell PowerEdge R710 early next week to confirm against 
the IDRAC . 

Ken

Original comment by bhms.rob...@gmail.com on 14 Sep 2013 at 3:02

[GoogleCodeExporter]

Documentation updated and options present in 2.0.0-beta-8, which will be 
available for download in the next few minutes.

Please let me know if this issue re-occurs under any conditions and re-open it 
if necessary.

Thanks again for all your help with this, Ken!

Original comment by red.hamsterx on 16 Sep 2013 at 3:36

• Changed state: Fixed