flan / staticdhcpd Goto Github PK

Using 'tftp_server_name' is an unusual way of passing the server information 
in.  The more standard option is to set 'siaddr' to the IP address of the 
server to retrieve the boot file from.  The PXE implementation on most desktops 
does not support DNS, and will not look at the tftp_server_name field.  From 
the example, 'Aastra 57i' looks like a VOIP phone, which is probably handling 
this differently.

Similarly, 'file' is usually used instead of bootfile_name.  For a standard PC 
client, they're generally expecting a PXE rom, not a config file.  I've used 
pxelinux.0 here, as it's the most common thing used.

So, the example would look like this:

packet.setOption('siaddr', ipToList(DHCP_SERVER_IP))
packet.setOption('file', strToPaddedList('pxelinux.0',128))

Hello. 
Documentation say ( 
http://static.uguu.ca/projects/staticDHCPd/doc/customisation/scripting.html?high
light=loaddhcppacket#loadDHCPPacket ) that loadDHCPPacket has 7 arg (packet, 
method, mac, definition, relay_ip, pxe, vendor) but in latest version only 6 no 
"vendor" param.

What steps will reproduce the problem?
1.Add the line: print packet 
 in dhcp_network.py's method  def _getNextDHCPPacket(self, timeout=60):
   ...
            if data:
                packet = dhcp_packet.DHCPPacket(data)
                print packet

2.
3.

What is the expected output? What do you see instead?
Exception traceback:
Traceback (most recent call last):
  File "/usr/local/Python-2.7/lib/python2.7/site-packages/staticdhcpd/src/dhcp.py", line 859, in run
    self._dhcp_server.getNextDHCPPacket()
  File "/usr/local/Python-2.7/lib/python2.7/site-packages/staticdhcpd/src/dhcp.py", line 793, in getNextDHCPPacket
    if self._getNextDHCPPacket():
  File "/usr/local/Python-2.7/lib/python2.7/site-packages/staticdhcpd/src/libpydhcpserver/dhcp_network.py", line 133, in _getNextDHCPPacket
    print packet
  File "/usr/local/Python-2.7/lib/python2.7/site-packages/staticdhcpd/src/libpydhcpserver/dhcp_packet.py", line 591, in __str__
    'type': DHCP_FIELDS_NAME['op'][op[0]],
NameError: global name 'DHCP_FIELDS_NAME' is not defined



What version of the product are you using? On what operating system?
1.5.4

Please provide any additional information below.
 DHCP_FIELDS_NAME should be: DHCP_FIELDS_NAMES

The INSERT INTO subnets SQL in the README has 9 columns but only 8 values.

I'm trying to boot iPXE ( http://www.ipxe.org/ , test iso available from 
http://boot.ipxe.org/ipxe.iso ) using staticdhcpd.  iPXE checks to confirm the 
source port of the DHCP response is port 67, but I can't seem to configure 
staticdhcpd to respond from this port.

Looking at libpydhcpserver, it seems that it supports this behavior, if 
server_address is not set, but staticdhcpd doesn't have any way to set this.

I was able to confirm this is the issue with this workaround:

--- staticdhcpd-read-only/libpydhcpserver/libpydhcpserver/dhcp_network.py       
2014-07-03 12:23:52.530983813 -0400
+++ /usr/lib/python2.6/site-packages/libpydhcpserver/dhcp_network.py    
2014-07-08 10:40:55.379334306 -0400
@@ -74,7 +74,7 @@
         @raise Exception: A problem occurred while binding the sockets.
         """
         try:
-            if self._server_address:
+            if self._server_address and False:
                 self._response_socket.bind((self._server_address, 0))
             self._dhcp_socket.bind(('', self._server_port))
             if self._pxe_port:
@@ -93,7 +93,7 @@
         """
         try:
             self._dhcp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
-            if self._server_address:
+            if self._server_address and False:
                 self._response_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
             else:
                 self._response_socket = self._dhcp_socket

Which causes the responses to be sent from port 67, and accepted by iPXE.  I do 
not see any way to configure this via conf.py

 - urlparse.parse_qs was copied from cgi module in python 2.6
 - error logging uses "errors" key, "error" is supplied

What is the expected output? What do you see instead?
Won't load on py2.5 and exceptions will not be printed, but raise a new 
exception.

What version of the product are you using? On what operating system?
svn trunk on debian lenny

Please provide any additional information below.
Patch attached.

I noticed that support for the RFC3442 (classless static route) option appears 
to be missing. 

http://tools.ietf.org/html/rfc3442

In particular, this requires encoding the ips/subnet masks in an odd way, which 
doesn't seem to exist yet.

Error handling (in the event of an exception) does not actually print a stack 
trace like it should.  You'll get messages like this:

2014-12-09 10:49:28,003 : CRITICAL : dhcp:166[Thread-2] : Unable to handle 
DISCOVER from  52:54:00:09:80:19:
None

This patch corrects it:

--- a/staticDHCPd/staticdhcpdlib/dhcp.py
+++ b/staticDHCPd/staticdhcpdlib/dhcp.py
@@ -163,7 +163,7 @@ class _PacketWrapper(object):
                 _logger.critical("Unable to handle %(type)s from  %(mac)s:\n%(error)s" % {
                  'type': self._packet_type,
                  'mac': self.mac,
-                 'error': traceback.format_exc(),
+                 'error': "\n".join(traceback.format_exception(type, value, 
tb)),
                 })
                 return True
         finally:


After the patch, you'll get errors like:

2014-12-09 10:53:14,004 : CRITICAL : dhcp:167[Thread-2] : Unable to handle 
DISCOVER from  52:54:00:09:80:19:
Traceback (most recent call last):

  File "/usr/lib/python2.6/site-packages/staticdhcpdlib/dhcp.py", line 392, in wrappedHandler
    f(self, wrapper)

  File "/usr/lib/python2.6/site-packages/staticdhcpdlib/dhcp.py", line 503, in _handleDHCPDiscover
    if wrapper.loadDHCPPacket(definition):

  File "/usr/lib/python2.6/site-packages/staticdhcpdlib/dhcp.py", line 347, in loadDHCPPacket
    self._original_packet

  File "/etc/staticDHCPd/conf.py", line 235, in loadDHCPPacket
    packet.setOption('domain_name_servers', ipToList("<%= @ipaddress_br0_global %>"))

  File "/usr/lib/python2.6/site-packages/libpydhcpserver/dhcp_types/conversion.py", line 230, in ipToList
    ip = _IPv4(ip)

  File "/usr/lib/python2.6/site-packages/libpydhcpserver/dhcp_types/ipv4.py", line 73, in __init__
    'ip': address,

ValueError: '<%= @ipaddress_br0_global %>' is not a valid IPv4: non-integer 
data supplied

Trying to start the latest 2.0.0 branch yields

014-06-26 09:33:01,437 : CRITICAL : System shutdown triggered by unhandled 
exception:
Traceback (most recent call last):
  File "/usr/local/bin/staticDHCPd", line 290, in <module>
    _initialise()
  File "/usr/local/bin/staticDHCPd", line 192, in _initialise
    web_logger = staticdhcpdlib.web.methods.Logger()
  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/web/methods.py", line 60, in __init__
    self._logger.setFormatter(logging.Formatter("%(asctime)s : %(message)s"))
AttributeError: 'Logger' object has no attribute '_logger'

I think changes in r688 are responsible for this.

Fabian

= From e-mail =

I am trying to use staticdhcpd (downloaded a few days ago) to support pxeboot.

Seems it is more than just add a few options related to booting (i.e., 
tftp_server_name, bootfile_name etc.) in dhcp._DHCPServer._loadDHCPPacket. As I 
got: PXE-E55: ProxyDHCP service did not reply to request on port 4011. 

To support pxeboot, we need both standard DHCP on port 67 and ProxyDHCP on port 
4011?

thanks,

Andrew

Hello.
After update from 2.0.0-beta-8 to 2.0.0-beta-12 server response to client witch 
wrong field "Default-Gateway":

    172.25.37.161.67 > 172.22.76.1.67: [bad udp cksum 0xcb52 -> 0xc5c6!] BOOTP/DHCP, Reply, length 359, hops 1, xid 0x1b3a, Flags [none] (0x0000)
      Your-IP 172.22.76.3
      Gateway-IP 172.22.76.1
      Client-Ethernet-Address 00:26:99:ef:0f:1a
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 172.25.37.161
        Lease-Time Option 51, length 4: 360000
        Subnet-Mask Option 1, length 4: 255.255.254.0
        Default-Gateway Option 3, length 16: 0.0.0.172,0.0.0.22,0.0.0.76,0.0.0.1
        Domain-Name-Server Option 6, length 8: 172.25.33.2,172.25.34.2
        Domain-Name Option 15, length 13: "voip.nc.local"
        TFTP Option 66, length 49: "http://g-voip.gs.slm/api/g-voip/get/device/config"
        END Option 255, length 0
        PAD Option 0, length 0, occurs 3
To Definition I put gateway '172.22.76.1' as string.
I am use httpdb, and Definition create as in example:
definition = Definition(
             ip=result['ip'], lease_time=result['lease_time'], subnet=result['subnet'], serial=result['serial'],
             hostname=result.get('hostname'),
             gateway=result.get('gateway'), subnet_mask=result.get('subnet_mask'), broadcast_address=result.get('broadcast_address'),
             domain_name=result.get('domain_name'), domain_name_servers=result.get('domain_name_servers'), ntp_servers=result.get('ntp_servers'),
             extra=result.get('extra'),
            )



Also in documentation for Definition ( 
http://static.uguu.ca/projects/staticDHCPd/doc/api/databases.html?highlight=defi
nition#databases.generic.Definition )  parameter name is "gateways" in source 
"gateway"

What steps will reproduce the problem?
1. set DAEMON=False in conf.py
2. execute python /usr/local/bin/staticDHCPd 
3. observe TraceBack


What is the expected output? What do you see instead?
tcpdump -n -ieth0 'ip proto \udp' and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:05:06.740527 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
48:5d:60:88:ec:d7, length 302

Instead of that what to respond DHCPOFFER staticDHCPd following Traceback

2013-06-19 20:05:10,204 : CRITICAL : Unable to handle INFORM from  
48:5d:60:88:ec:d7:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 439, in wrappedHandler
    f(self, wrapper)
  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 588, in _handleDHCPInform
    definition = wrapper.retrieveDefinition(override_ip, override_ip_value=wrapper.ciaddr)
NameError: global name 'override_ip' is not defined


What version of the product are you using? On what operating system?
staticDHCPd-2.0.0-beta-2 
Ubuntu 13.04 x86

Please provide any additional information below.

After a DHCP discover, wait for the client to renew the lease. When it does, on 
attempting to respond, the exception

AttributeError: 'tuple' object has no attribute 'ip'

will be raised, and the response will not be sent.

This is with 2.0.0-beta11

The fix is to use the Address named tuple from libpydhcpserver, and the diff is:

Index: staticdhcpdlib/dhcp.py
===================================================================
--- staticdhcpdlib/dhcp.py  (revision 678)
+++ staticdhcpdlib/dhcp.py  (working copy)
@@ -651,49 +651,49 @@
     def _handleDHCPRequest_RENEW_REBIND(self, wrapper):
         renew = wrapper.source_address.ip not in libpydhcpserver.dhcp.IP_UNSPECIFIED_FILTER
         wrapper.setType(renew and _PACKET_TYPE_REQUEST_RENEW or _PACKET_TYPE_REQUEST_REBIND)
         if not wrapper.filterPacket(): return
         wrapper.announcePacket(ip=wrapper.ip)

         if config.NAK_RENEWALS and not wrapper.pxe and (renew or config.AUTHORITATIVE):
             wrapper.packet.transformToDHCPNakPacket()
             self._emitDHCPPacket(
              wrapper.packet, wrapper.source_address, wrapper.pxe,
              wrapper.mac, _IP_REJECTED
             )
             wrapper.markAddressed()
         else:
             definition = wrapper.retrieveDefinition()
             if definition and definition.ip == wrapper.ciaddr:
                 wrapper.packet.transformToDHCPAckPacket()
                 wrapper.packet.setOption('yiaddr', wrapper.ciaddr)
                 if wrapper.loadDHCPPacket(definition):
                     self._emitDHCPPacket(
-                     wrapper.packet, (wrapper.ciaddr, 0), wrapper.pxe,
+                     wrapper.packet, 
libpydhcpserver.dhcp.Address(wrapper.ciaddr, 0), wrapper.pxe,
                      wrapper.mac, wrapper.ciaddr
                     )
                     wrapper.markAddressed()
             else:
                 if renew:
                     wrapper.packet.transformToDHCPNakPacket()
                     self._emitDHCPPacket(
-                     wrapper.packet, (wrapper.ciaddr, 0), wrapper.pxe,
+                     wrapper.packet, 
libpydhcpserver.dhcp.Address(wrapper.ciaddr, 0), wrapper.pxe,
                      wrapper.mac, wrapper.ciaddr
                     )
                     wrapper.markAddressed()

     @_dhcpHandler(_PACKET_TYPE_RELEASE)
     def _handleDHCPRelease(self, wrapper):
         """
         Handles a client that has terminated its "lease".

         @type wrapper: L{_PacketWrapper}
         @param wrapper: A wrapper around the packet, exposing helpful details.
         """
         if not wrapper.sid:
             raise _PacketSourceBlacklist("server-identifier was not specified")

         if wrapper.sid == self._server_address: #Released!
             if not wrapper.filterPacket(override_ip=True, override_ip_value=wrapper.ciaddr): return
             definition = wrapper.retrieveDefinition(override_ip=True, override_ip_value=wrapper.ciaddr)
             if definition and definition.ip == wrapper.ciaddr: #Known client.
                 wrapper.announcePacket(ip=wrapper.ciaddr)

What steps will reproduce the problem?
1.Start the process via running 'python -OO main.py'
2.
3.

What is the expected output? What do you see instead?

In the first a few minutes, can see incoming dhcp request, after
a few minutes (say 5 minutes), it seems to be no longer responsive.
Another way to show the problem is: a client can pxe boot in the first
a few minutes when the staticdhcpd is running. Later it won't be able to 
pxeboot.

What version of the product are you using? On what operating system?

1.4.3 on Redhat El4 U3

Please provide any additional information below.

Had an instance of ISC's dhcpd (v3.0.1) running on the same server.
Did a tail -f /var/log/messages, can see it processing incoming dhcp requests 
while staticdhcpd stalled.

Hi Neil,

buried in my httpdb configuration commit was another small bugfix for the 
httpdb module.
I'm opening another issue so this can be fixed right away without waiting for 
whatever comes out of i22.

Cheers,
Fabian

What steps will reproduce the problem?
1.PXE boot a host on the same subnet as dhcp server to Redhat EL4 U7/U8 
2.
3.

What is the expected output? What do you see instead?
The boot fails at the stage when it tries to obtain IP information.

What version of the product are you using? On what operating system?
staticdhcpd running on enterprise linux EL5 U4.

Please provide any additional information below.
-This does not happen if the host is on a different subnet, when the packets 
are forwarded by a router instead of through broadcast.
-When the host boots up, the first round of discover/offer/request/acknowledge 
happens without issue. As the host starts to image, it needs to get ip address 
information for a second time, that is when
it hangs. By looking at the debug info, looks like the discover/offer
did happen, it seems the host did not submit a request or the request was not 
picked up.
-ISC dhcp was able to handle this without problem.
-This does not happen with higher version of Redhat enterprise, non of the EL5 
had this issue. Nor did Solaris 11, Suse 9/10/11 has this issue.

What steps will reproduce the problem?
1.Two interfaces, one private, one public. PXE boot from private interface.
2.
3.

What is the expected output? What do you see instead?
The tftp boot starts but it hangs after trying to load cfg/<mac address> file.

The same setup works under ISC dhcpd.

What version of the product are you using? On what operating system?
1.4.3 Redhat EL4U2, PXELINUX 3.06

Please provide any additional information below.

Searched online, this problem happened when the 'next server' is not
set in ISC's /etc/dhcpd.conf. See this link:
http://syslinux.zytor.com/archives/2005-September/005879.html

But I checked the 'ACK' packet sent out, the tftp_server_name is
set correctly, the following is the packet's option data:

k,v server_identifier, [144, 25, 17, 84] 
k,v bootfile_name, [112, 120, 101, 108, 105, 110, 117, 120, 46, 98, 105, 110] 
k,v client_system, [0, 0] 
k,v client_ndi, [1, 2, 1] 
k,v uuid_guid, [0, 68, 69, 76, 76, 74, 0, 16, 86, 128, 51, 199, 192, 79, 67, 
68, 49] 
k,v hostname, [114, 119, 115, 54, 48, 48, 48, 49, 116, 111, 118, 109] 
k,v tftp_server_name, [49, 52, 52, 46, 50, 53, 46, 49, 55, 46, 56, 52] 
k,v subnet_mask, [255, 255, 252, 0] 
k,v requested_ip_address, [144, 25, 16, 102] 
k,v dhcp_message_type, [5] 
k,v ip_address_lease_time, [52, 51, 50, 48, 48] 
k,v maximum_dhcp_message_size, [4, 236] 

Anything obvious here?

I'm attempting to boot v2.0.0 with iPXE.  I'm getting the following exception 
on every DHCP packet:

Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/root/staticdhcpd-read-only-2/staticDHCPd/staticdhcpdlib/dhcp.py", line 391, in wrappedHandler
    f(self, wrapper)
  File "/root/staticdhcpd-read-only-2/staticDHCPd/staticdhcpdlib/dhcp.py", line 498, in _handleDHCPDiscover
    if wrapper.loadDHCPPacket(definition):
  File "/root/staticdhcpd-read-only-2/staticDHCPd/staticdhcpdlib/dhcp.py", line 346, in loadDHCPPacket
    self._original_packet
  File "/root/staticdhcpd-read-only-2/staticDHCPd/staticdhcpdlib/config.py", line 215, in <lambda>
    (pxe.client_system, pxe.client_ndi, pxe.uuid_guid),
AttributeError: 'NoneType' object has no attribute 'client_system'

The DHCP request looks like this:

14:53:06.602518 IP (tos 0x0, ttl 64, id 1821, offset 0, flags [none], proto UDP 
(17), length 427)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:9e:be:28, length 399, xid 0x65eea51e, secs 12, Flags [none] (0x0000)
          Client-Ethernet-Address 52:54:00:9e:be:28
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            MSZ Option 57, length 2: 1472
            ARCH Option 93, length 2: 0
            NDI Option 94, length 3: 1.2.1
            Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
            CLASS Option 77, length 4: "iPXE"
            Parameter-Request Option 55, length 22:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, LOG
              Hostname, Domain-Name, RP, Vendor-Option
              Vendor-Class, TFTP, BF, Option 119
              Option 128, Option 129, Option 130, Option 131
              Option 132, Option 133, Option 134, Option 135
              Option 175, Option 203
            T175 Option 175, length 48: 2969895194,4094689515,50397184,402719010,16849153,18940161,268501523,16847873,17891585,385941781,16852737,17957121
            Client-ID Option 61, length 7: ether 52:54:00:9e:be:28
            GUID Option 97, length 17: 0.45.158.189.9.238.241.69.235.155.61.238.195.25.10.140.167
            END Option 255, length 0


I *do* have loadDHCPPacket defined in conf.py.

What steps will reproduce the problem?
1. Create a db entry for a MAC like this "00:25:90:88:C4:0A"
2. When the DISCOVER comes in like this "00:25:90:88:c4:0a" it won't match the 
db entry. 

What is the expected output? What do you see instead?
Matching should be case insensitive. 

What version of the product are you using? On what operating system?
staticDHCPd 2.0.0-599 with sqlite3 3.8.0.1 on SLES11sp3

Please provide any additional information below.
Barcode label on the server itself is all uppercase but dhcp request is all 
lower case. 

On the latest source of libpydhcpserver on the 2.0.0 branch (bug introduced in 
r682), the getFlag function has the wrong variable name, resulting in an 
exception.

This is easily fixed:

Index: branches/2.0.0/libpydhcpserver/libpydhcpserver/dhcp_types/packet.py
===================================================================
--- 
branches/2.0.0/libpydhcpserver/libpydhcpserver/dhcp_types/packet.py (revision 
698)
+++ 
branches/2.0.0/libpydhcpserver/libpydhcpserver/dhcp_types/packet.py (working 
copy)
@@ -492,21 +492,21 @@
         self.setOption('flags', [flags >> 8 & 0xFF, flags & 0xFF])

     def getFlag(self, bitflag):
         """
         Retrieves a flag-bit from the header.

         :param int bitflag: One of the flag-constants defined in this module,
                             like ``FLAGBIT_BROADCAST``.
         :return bool: The state of the bit.
         """
-        return bool(self._getFlags() & flag)
+        return bool(self._getFlags() & bitflag)

     def setFlag(self, bitflag, state):
         """
         Modifies the header to set a flag-bit.

         :param int bitflag: One of the flag-constants defined in this module,
                             like ``FLAGBIT_BROADCAST``.
         :param bool state: Whether the bit should be set or not.
         :return tuple(2): Whether the bit was changed and its initial value,
                           expressed in boolean.

Should be:

if not conf.POSTGRESQL_HOST:

What steps will reproduce the problem?
1.Some incoming packets seemed to have null body.
For example, a packet like:
[1, 1, 6, 1, 2, 97, 112, 101, 167, 123, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 139, 185, 141, 2, 0, 23, 239, 241, 248, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, ... 99, 130, 83, 99, 255, 0, 0, 0, 0, 0, 0, 0, ...]
The magic cookie is at its normal position, but the next byte is '255'.
Because the magic cookie is set correctly, it is deemed as a valid dhcp packet. 
In dhcp_network.py's '_getNextDHCPPacket', there are following logic:

 if data:
                packet = dhcp_packet.DHCPPacket(data)
                if packet.isDHCPPacket():
                    pxe = source_address[1] == self._pxe_port
                    if packet.isDHCPRequestPacket():
                        threading.Thread(target=self._handleDHCPRequest, args=(packet, source_address, pxe)) ...

Because it is a packet with empty body, the if packet.isDHCPRequestPacket() 
will trigger exception like:

   return self.getOption('dhcp_message_type')[0] == 1
TypeError: 'NoneType' object is not subscriptable

I added a line in dhcp_network.py's '_getNextDHCPPacket'
to avoid this, not sure if this is correct, please let me know.
Thanks!

      packet = dhcp_packet.DHCPPacket(data)

      if not packet._options_data: return False  # some packets only have header, need to skip them

      if packet.isDHCPPacket():

2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?

1.4.3 on Redhat el4 u3

Please provide any additional information below.

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 ?

I ran into an issue where NAKs are being sent in response to REQUEST:RENEW 
packets, even when the server is not configured in authoritative mode:

2015-05-14 16:40:25,043 : DEBUG : dhcp:246[Thread-151] : REQUEST from 
56:00:00:09:2d:bb via x.x.x.x:68
2015-05-14 16:40:25,043 : INFO : dhcp:246[Thread-151] : REQUEST:RENEW from 
56:00:00:09:2d:bb via x.x.x.x:68
2015-05-14 16:40:25,044 : INFO : dhcp:771[Thread-151] : NAK sent at 
56:00:00:09:2d:bb for x.x.x.x via x.x.x.x:68 [253 bytes]
2015-05-14 16:40:25,044 : DEBUG : dhcp:180[Thread-151] : REQUEST:RENEW request 
from 56:00:00:09:2d:bb processed in 0.0014 seconds

I have the following config:

AUTHORITATIVE = False
NAK_RENEWALS = False

Also, the server does not have a lease configured for this MAC address.

This issue appears to be within _handleDHCPRequest_RENEW_REBIND.  This function 
will send a NAK if it cannot find a DHCP lease for a MAC address.

I fixed it with this patch:

--- a/staticDHCPd/staticdhcpdlib/dhcp.py
+++ b/staticDHCPd/staticdhcpdlib/dhcp.py
@@ -677,7 +677,7 @@ class _DHCPServer(libpydhcpserver.dhcp.DHCPServer):
                      wrapper.mac, wrapper.ciaddr
                     )
                     wrapper.markAddressed()
-            else:
+            elif definition or config.AUTHORITATIVE:
                 if renew:
                     wrapper.packet.transformToDHCPNakPacket()
                     self._emitDHCPPacket(

So, we'll only send a NAK back in response to a RENEW if we can find a valid 
lease, or we're in AUTHORITATIVE mode.

What steps will reproduce the problem?
1. sync'd to the latest 2.0.0 branch code (669)
2.
3.

What is the expected output? What do you see instead?
No Unhandled Exceptions.  See Additional Info below. 

What version of the product are you using? On what operating system?
2.0.0-669 on SLES11 sp3 

Please provide any additional information below.

I get the following error in the logfile shortly after starting staticDHCPd. 

2013-10-29 21:09:40,694 : CRITICAL : Unhandled exception:
Traceback (most recent call last):
  File "/VISTA/system/network/dhcpd/staticDHCPd/staticdhcpdlib/dhcp.py", line 908, in run
    self._dhcp_server.getNextDHCPPacket()
  File "/VISTA/system/network/dhcpd/staticDHCPd/staticdhcpdlib/dhcp.py", line 824, in getNextDHCPPacket
    (dhcp_received, source_address) = self._getNextDHCPPacket()
  File "/VISTA/system/network/dhcpd/staticDHCPd/libpydhcpserver/dhcp.py", line 104, in _getNextDHCPPacket
    if packet.isDHCPRequestPacket():
  File "/VISTA/system/network/dhcpd/staticDHCPd/libpydhcpserver/dhcp_types/packet.py", line 779, in isDHCPRequestPacket
    return self._getDHCPMessageType() == 3
  File "/VISTA/system/network/dhcpd/staticDHCPd/libpydhcpserver/dhcp_types/packet.py", line 662, in _getDHCPMessageType
    dhcp_message_type = self.getOption(53)
  File "/VISTA/system/network/dhcpd/staticDHCPd/libpydhcpserver/dhcp_types/packet.py", line 524, in getOption
    id = self._getOptionID(option)
  File "/VISTA/system/network/dhcpd/staticDHCPd/libpydhcpserver/dhcp_types/packet.py", line 411, in _getOptionID
    if id is None:
UnboundLocalError: local variable 'id' referenced before assignment

What steps will reproduce the problem?
1. Install CentOS 7
2. Download 2.0.0 and install.py
3. Configure conf.py
4. Disable email. (Another bug I guess)
5. Disable daemon
6. Run staticDHCPd

What is the expected output? What do you see instead?

2014-09-17 10:12:07,263 : INFO : Console-based logging online
2014-09-17 10:12:07,263 : INFO : Configuring file-based logging for 
/var/log/dhcp2.log...
2014-09-17 10:12:07,263 : INFO : Configured rotation-based logging for file, 
with history=7 days
2014-09-17 10:12:07,264 : INFO : File-based logging online
2014-09-17 10:12:07,264 : WARNING : ----------------------------------------
2014-09-17 10:12:07,264 : WARNING : ----------------------------------------
2014-09-17 10:12:07,264 : WARNING : ----------------------------------------
2014-09-17 10:12:07,264 : WARNING : System startup in progress; PID=14067
2014-09-17 10:12:07,264 : WARNING : staticDHCPd version 2.0.0-rc1 : 
http://uguu.ca/
2014-09-17 10:12:07,265 : WARNING : libpydhcpserver version 2.0.0-rc1 : 
http://uguu.ca/
2014-09-17 10:12:07,265 : WARNING : Continuing with subsystem initialisation
2014-09-17 10:12:07,265 : WARNING : ----------------------------------------
2014-09-17 10:12:07,265 : WARNING : Pidfile already exists, with PID 14027
2014-09-17 10:12:07,265 : INFO : Webservice module enabled; configuring...
2014-09-17 10:12:07,296 : INFO : Prepared to bind to 0.0.0.0:30880
2014-09-17 10:12:07,297 : INFO : Configured Webservice engine
2014-09-17 10:12:07,297 : INFO : Webservice engine beginning normal operation
2014-09-17 10:12:07,299 : INFO : Webservice logging module enabled; 
configuring...
2014-09-17 10:12:07,299 : INFO : Configuring web-accessible logging...
2014-09-17 10:12:07,299 : INFO : Web-accessible logging online; buffer-size=200
2014-09-17 10:12:07,299 : INFO : Initialising custom code...
2014-09-17 10:12:07,301 : WARNING : eventlet is not available; falling back to 
unpooled mode
2014-09-17 10:12:07,315 : INFO : Prepared to bind to 10.210.0.23; ports: 
server: 67, client: 68, pxe: None
2014-09-17 10:12:07,324 : INFO : Configured DHCP server
2014-09-17 10:12:07,325 : INFO : DHCP engine beginning normal operation
2014-09-17 10:12:07,326 : INFO : Changing runtime permissions to UID=99, 
GID=99...
2014-09-17 10:12:07,326 : WARNING : ----------------------------------------
2014-09-17 10:12:07,326 : WARNING : All subsystems initialised; now serving
2014-09-17 10:12:07,326 : WARNING : ----------------------------------------
2014-09-17 10:12:08,072 : INFO : INFORM from 34:17:eb:b2:c3:e0 for 128.8.0.82 
via 128.8.0.82:68
2014-09-17 10:12:08,093 : CRITICAL : Unable to handle INFORM from  
34:17:eb:b2:c3:e0:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/staticdhcpdlib/dhcp.py", line 391, in wrappedHandler
    f(self, wrapper)
  File "/usr/lib/python2.7/site-packages/staticdhcpdlib/dhcp.py", line 537, in _handleDHCPInform
    definition = wrapper.retrieveDefinition(override_ip=True, override_ip_value=wrapper.ciaddr)
  File "/usr/lib/python2.7/site-packages/staticdhcpdlib/dhcp.py", line 375, in retrieveDefinition
    self.pxe and self._pxe_options or None
TypeError: <lambda>() takes exactly 7 arguments (6 given)

2014-09-17 10:12:09,006 : INFO : INFORM from 00:13:20:80:2e:f7 for 128.8.5.16 
via 128.8.5.16:68
2014-09-17 10:12:09,008 : CRITICAL : Unable to handle INFORM from  
00:13:20:80:2e:f7:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/staticdhcpdlib/dhcp.py", line 391, in wrappedHandler
    f(self, wrapper)
  File "/usr/lib/python2.7/site-packages/staticdhcpdlib/dhcp.py", line 537, in _handleDHCPInform
    definition = wrapper.retrieveDefinition(override_ip=True, override_ip_value=wrapper.ciaddr)
  File "/usr/lib/python2.7/site-packages/staticdhcpdlib/dhcp.py", line 375, in retrieveDefinition
    self.pxe and self._pxe_options or None
TypeError: <lambda>() takes exactly 7 arguments (6 given)


What version of the product are you using? On what operating system?

2.0.0

Please provide any additional information below.

I used the my old conf file but I had to disable email because it kept 
complaining about a timeout error and then would crash. After disabled that I 
get the above error over and over when a client makes a request to the server. 
The error is not only on INFORM but DISCOVER also.

What steps will reproduce the problem?
1. Delete static lease entry - on client renew (etc) the dhcpd will send NAKs

What is the expected output? What do you see instead?
It should not send NAKs.

What version of the product are you using? On what operating system?
SVN trunk on Debian Lenny

Please provide any additional information below.
Patch attached.

I tested but not working under VirtualBox.

Statistics:
Thu Feb 7 13:44:38 2013 : received: 5; discarded: 0; turnaround: 0.000638s/pkt; 
ignored MACs: 0
Thu Feb 7 13:44:08 2013 : received: 0; discarded: 0; turnaround: 0.000000s/pkt; 
ignored MACs: 0
Thu Feb 7 13:43:38 2013 : received: 0; discarded: 0; turnaround: 0.000000s/pkt; 
ignored MACs: 0
Thu Feb 7 13:43:08 2013 : received: 1; discarded: 1; turnaround: 0.000826s/pkt; 
ignored MACs: 1
Thu Feb 7 13:42:38 2013 : received: 0; discarded: 0; turnaround: 0.000000s/pkt; 
ignored MACs: 0
Thu Feb 7 13:42:08 2013 : received: 1; discarded: 0; turnaround: 0.000658s/pkt; 
ignored MACs: 0
Thu Feb 7 13:41:38 2013 : received: 3; discarded: 0; turnaround: 0.000760s/pkt; 
ignored MACs: 0

Events:
Thu Feb 7 13:44:53 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:53 2013 : DHCPDISCOVER from 08:00:27:1f:96:64
Thu Feb 7 13:44:52 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:52 2013 : DHCPDISCOVER from 08:00:27:1f:96:64
Thu Feb 7 13:44:43 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:43 2013 : DHCPDISCOVER from 08:00:27:1f:96:64
Thu Feb 7 13:44:37 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:37 2013 : DHCPDISCOVER from 08:00:27:1f:96:64
Thu Feb 7 13:44:34 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:34 2013 : DHCPDISCOVER from 08:00:27:1f:96:64
Thu Feb 7 13:44:32 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:32 2013 : DHCPDISCOVER from 08:00:27:1f:96:64
Thu Feb 7 13:44:20 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:20 2013 : DHCPDISCOVER from 08:00:27:1f:96:64
Thu Feb 7 13:44:14 2013 : DHCPNAK sent to 08:00:27:1f:96:64 for ?.?.?.? via 
255.255.255.255:68 [250 bytes]
Thu Feb 7 13:44:14 2013 : DHCPDISCOVER from 08:00:27:1f:96:64

Clients using the rapid-commit DHCP option generate an error:

2014-12-09 11:27:47,330 : INFO : dhcp:495[Thread-43] : DISCOVER from 
52:54:00:09:80:19 requested rapid-commit
<type 'exceptions.ValueError'> Expected a value of length 0, not 0: [] 
<traceback object at 0x190c050>
2014-12-09 11:27:47,330 : CRITICAL : dhcp:167[Thread-43] : Unable to handle 
DISCOVER from  52:54:00:09:80:19:
Traceback (most recent call last):

  File "/usr/lib/python2.6/site-packages/staticdhcpdlib/dhcp.py", line 392, in wrappedHandler
    f(self, wrapper)

  File "/usr/lib/python2.6/site-packages/staticdhcpdlib/dhcp.py", line 498, in _handleDHCPDiscover
    wrapper.packet.setOption(80, [])

  File "/usr/lib/python2.6/site-packages/libpydhcpserver/dhcp_types/packet.py", line 668, in setOption
    'value': value,

ValueError: Expected a value of length 0, not 0: []


The only client I can find that does this is 
http://roy.marples.name/projects/dhcpcd/index  You'd also need a config file 
like: https://raw.githubusercontent.com/bldewolf/dhcpcd/master/dhcpcd.conf 
,then you can run with:

pkill dhcpcd; sleep 1; ./dhcpcd -f /root/dhcpcd-6.6.4/conf.conf -d

I fixed it with this patch, though I'm not clear about what this check was for 
originally:

--- a/libpydhcpserver/libpydhcpserver/dhcp_types/packet.py
+++ b/libpydhcpserver/libpydhcpserver/dhcp_types/packet.py
@@ -661,7 +661,7 @@ class DHCPPacket(object):
                              'value-length': length,
                              'value': value,
                             })
-                    elif not fixed_length:
+                    elif not fixed_length and minimum_length > 0:
                         raise ValueError("Expected a value of length %(length)i, not %(value-length
                          'length': fixed_length,
                          'value-length': length,

What steps will reproduce the problem?
1. set DAEMON=True in conf.py
2. execute staticDHCPd
3. observe TraceBack

What is the expected output? What do you see instead?
staticDHCPd to launch and detach from console.
Instead staticDHCPd exits with the following Traceback

Traceback (most recent call last):
  File "/usr/local/bin/staticDHCPd", line 95, in <module>
    _daemonise()
  File "/usr/local/bin/staticDHCPd", line 86, in _daemonise
    os.dup2(open('/dev/null', 'r').fileno(), sys.stdin.fileno())
OSError: [Errno 9] Bad file descriptor



What version of the product are you using? On what operating system?
Using Trunk on Ubuntu 12.04 x64

Please provide any additional information below.
replacing the current os.dup2() commands with the following resolves the issue.

    si = open('/dev/null', 'r')
    so = open('/dev/null', 'a+')
    se = open('/dev/null', 'a+', 0)
    os.dup2(si.fileno(), sys.stdin.fileno())
    os.dup2(so.fileno(), sys.stdout.fileno())
    os.dup2(se.fileno(), sys.stderr.fileno())

There is a typo in the config.py file of the staticdhcplib package.  I 
discovered it trying to use the custom loadDHCPPacket handler in 
staticDHCPd-2.0.0-beta-9.

The error is on line 206, it inspects the arguments of the wrong function.  
Here's the incorrect line:

    if inspect.getargspec(conf.handleUnknownMAC).args == ['packet', 'mac', 'client_ip', 'relay_ip', 'subnet', 'serial', 'pxe', 'vendor']:

Which should be replaced with:

    if inspect.getargspec(conf.loadDHCPPacket).args == ['packet', 'mac', 'client_ip', 'relay_ip', 'subnet', 'serial', 'pxe', 'vendor']:

What steps will reproduce the problem?
1. Install 2.0.0-beta-9
2. Setup a custom handler for the loadDHCPPacket handler
3. Start the daemon

What version of the product are you using? On what operating system?

Sotware Version: staticdhcpd-2.0.0-beta-9
Operating System: CentOS 6.6

Using SVN revision 739, daemon mode crashes with the following error on CentOS 
6 (which is python 2.6.6):

Traceback (most recent call last):
  File "staticDHCPd", line 97, in <module>
    _daemonise()
  File "staticDHCPd", line 88, in _daemonise
    os.dup2(open('/dev/null', 'r').fileno(), sys.stdin.fileno())
OSError: [Errno 9] Bad file descriptor

The following patch corrects this issue:

--- staticDHCPd 2014-07-03 12:23:52.672985694 -0400
+++ /usr/bin/staticDHCPd        2014-07-07 17:21:59.000000000 -0400
@@ -85,9 +85,12 @@
     os.chdir('/') #Avoid holding references to unstable resources

     #And lastly, clean up the base descriptors
-    os.dup2(open('/dev/null', 'r').fileno(), sys.stdin.fileno())
-    os.dup2(open('/dev/null', 'a+').fileno(), sys.stdout.fileno())
-    os.dup2(open('/dev/null', 'a+', 0).fileno(), sys.stderr.fileno())
+    devnull = os.open('/dev/null', os.O_RDWR)
+
+    os.dup2(devnull, sys.stdout.fileno())
+    os.dup2(devnull, sys.stderr.fileno())
+    os.dup2(devnull, sys.stdin.fileno())
+

 if __name__ == '__main__':
     #Ensure that pre-setup tasks are taken care of.

Configure a lease, setup PXE configuration in conf.py
    packet.setOption(60, strToList('PXEClient'))
    packet.setOption(66, strToList('1.1.1.1'))
    packet.setOption(67, strToList('/pxelinux.0'))

If you boot the system, the first stage DHCP server response is correct.
When the PXE rom starts sending requests to the DHCP server on port 4011, it 
never responds. Regular DHCP operation does function on the normal ports while 
this is happening.

I've tried with Python 2.6+2.7 on FreeBSD and Linux.

Hello on latest svn version problem witch Cisco IP Phone CP-7911G. 
Her request trace:
09:25:53.180318 IP (tos 0x0, ttl 252, id 8292, offset 0, flags [none], proto 
UDP (17), length 576)
    172.22.76.1.67 > 172.25.37.161.67: [udp sum ok] BOOTP/DHCP, Request from 00:26:99:ef:0f:1a, length 548, hops 1, xid 0x1b3a, secs 48, Flags [Broadcast] (0x8000)
          Gateway-IP 172.22.76.1
          Client-Ethernet-Address 00:26:99:ef:0f:1a
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 7: ether 00:26:99:ef:0f:1a
            Hostname Option 12, length 15: "SEP002699EF0F1A"
            Vendor-Class Option 60, length 38: "Cisco Systems, Inc. IP Phone CP-7911G^@"
            Parameter-Request Option 55, length 7: 
              Subnet-Mask, TFTP, Domain-Name-Server, Default-Gateway
              Domain-Name, Option 150, AT
            END Option 255, length 0
            PAD Option 0, length 0, occurs 229
09:25:53.190363 IP (tos 0x0, ttl 64, id 460, offset 0, flags [DF], proto UDP 
(17), length 375)
    172.25.37.161.67 > 172.22.76.1.67: [bad udp cksum 0xcb46 -> 0xc8e7!] BOOTP/DHCP, Reply, length 347, hops 1, xid 0x1b3a, Flags [none] (0x0000)
          Your-IP 172.22.76.3
          Gateway-IP 172.22.76.1
          Client-Ethernet-Address 00:26:99:ef:0f:1a
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: 172.25.37.161
            Lease-Time Option 51, length 4: 360000
            Subnet-Mask Option 1, length 4: 255.255.254.0
            Default-Gateway Option 3, length 4: 172.22.76.1
            Domain-Name-Server Option 6, length 8: 172.25.33.2,172.25.34.2
            Domain-Name Option 15, length 13: "voip.nc.local"
            TFTP Option 66, length 49: "http://g-voip.gs.slm/api/g-voip/get/device/config"
            END Option 255, length 0
            PAD Option 0, length 0, occurs 3


Phone not get ip address, and continues send "Discover" request to server. 
When I run isc-dhcp-server, phone get address request trace: 

09:28:57.197726 IP (tos 0x0, ttl 252, id 8379, offset 0, flags [none], proto 
UDP (17), length 576)
    172.22.76.1.67 > 172.25.37.161.67: [udp sum ok] BOOTP/DHCP, Request from 00:26:99:ef:0f:1a, length 548, hops 1, xid 0x1b3a, secs 120, Flags [Broadcast] (0x8000)
      Gateway-IP 172.22.76.1
      Client-Ethernet-Address 00:26:99:ef:0f:1a
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Client-ID Option 61, length 7: ether 00:26:99:ef:0f:1a
        Hostname Option 12, length 15: "SEP002699EF0F1A"
        Vendor-Class Option 60, length 38: "Cisco Systems, Inc. IP Phone CP-7911G^@"
        Parameter-Request Option 55, length 7: 
          Subnet-Mask, TFTP, Domain-Name-Server, Default-Gateway
          Domain-Name, Option 150, AT
        END Option 255, length 0
        PAD Option 0, length 0, occurs 229
09:28:57.198042 IP (tos 0x0, ttl 64, id 466, offset 0, flags [DF], proto UDP 
(17), length 328)
    172.25.37.161.67 > 172.22.76.1.67: [bad udp cksum 0xcb17 -> 0x9fe6!] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x1b3a, secs 120, Flags [Broadcast] (0x8000)
      Your-IP 172.22.76.3
      Gateway-IP 172.22.76.1
      Client-Ethernet-Address 00:26:99:ef:0f:1a
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 172.25.37.161
        Lease-Time Option 51, length 4: 600
        Subnet-Mask Option 1, length 4: 255.255.254.0
        Domain-Name-Server Option 6, length 8: 172.25.33.2,172.25.34.2
        Default-Gateway Option 3, length 4: 172.22.76.1
            Domain-Name Option 15, length 13: "voip.nc.local"
            TFTP Option 66, length 49: "http://g-voip.gs.slm/api/g-voip/get/device/config"
        END Option 255, length 0
        PAD Option 0, length 0, occurs 9
09:28:57.203809 IP (tos 0x0, ttl 252, id 8381, offset 0, flags [none], proto 
UDP (17), length 576)
    172.22.76.1.67 > 172.25.37.161.67: [udp sum ok] BOOTP/DHCP, Request from 00:26:99:ef:0f:1a, length 548, hops 1, xid 0x1b3a, Flags [Broadcast] (0x8000)
      Gateway-IP 172.22.76.1
      Client-Ethernet-Address 00:26:99:ef:0f:1a
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        Server-ID Option 54, length 4: 172.25.37.161
        Client-ID Option 61, length 7: ether 00:26:99:ef:0f:1a
        Hostname Option 12, length 15: "SEP002699EF0F1A"
        Vendor-Class Option 60, length 38: "Cisco Systems, Inc. IP Phone CP-7911G^@"
        Requested-IP Option 50, length 4: 172.22.76.3
        Parameter-Request Option 55, length 7: 
          Subnet-Mask, TFTP, Domain-Name-Server, Default-Gateway
          Domain-Name, Option 150, AT
        END Option 255, length 0
        PAD Option 0, length 0, occurs 217
09:28:57.203904 IP (tos 0x0, ttl 64, id 467, offset 0, flags [DF], proto UDP 
(17), length 328)
    172.25.37.161.67 > 172.22.76.1.67: [bad udp cksum 0xcb17 -> 0x9d5e!] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x1b3a, Flags [Broadcast] (0x8000)
      Your-IP 172.22.76.3
      Gateway-IP 172.22.76.1
      Client-Ethernet-Address 00:26:99:ef:0f:1a
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 172.25.37.161
        Lease-Time Option 51, length 4: 600
        Subnet-Mask Option 1, length 4: 255.255.254.0
        Domain-Name-Server Option 6, length 8: 172.25.33.2,172.25.34.2
        Default-Gateway Option 3, length 4: 172.22.76.1
            Domain-Name Option 15, length 13: "voip.nc.local"
            TFTP Option 66, length 49: "http://g-voip.gs.slm/api/g-voip/get/device/config"
        END Option 255, length 0
        PAD Option 0, length 0, occurs 9

What steps will reproduce the problem?
1. PXE booting a client to WinPE image
2.
3.

What is the expected output? What do you see instead?

The client was able to obtain bootfile and configuration file on PXE server. 
But when it tried to download the WinPE binary via tftp, it fails with the 
message:
    'TFTP download failed
  Press any key to reboot.'

The same setup worked for ISC dhcpd (V3.0.1). For detailed information from 
/var/log/messages file, please see attached file. I have listed the different 
response sequence under ISC and staticdhcpd.


What version of the product are you using? On what operating system?

staticdhcpd 1.5.3
pxe redhat el4u2
pxelinux 3.72
tftpd 0.39-3


Please provide any additional information below.

The client's pxe config file is:

default 1
timeout 1
prompt 1
label 1
kernel Boot/pxeboot.0
append -

/etc/default/tftpd.rules is as follows:

#Required for WinPE PXE support
rg \\boot.ini /boot.ini
rg \\Boot\\BCD /Boot/BCD
rg \\Boot\\boot.sdi /Boot/boot.sdi
rg \\Boot\\BOOT.WIM /Boot/BOOT.WIM
rg \\Boot\\Fonts\\wgl4_boot.ttf /Boot/Fonts/wgl4_boot.ttf
rg \\hiberfil.sys /hiberfil.sys 

What steps will reproduce the problem?
1. Configured dynamism in conf.py
2. Started staticDHCPd in non-daemon mode
3. waited for next dhcp request

What is the expected output? What do you see instead?

TypeError: __init__() got an unexpected keyword argument 'gateway'

What version of the product are you using? On what operating system?

2.0.0 rc1

Please provide any additional information below.

Full console output: 

2015-05-02 11:09:32,226 : WARNING : ----------------------------------------
2015-05-02 11:09:32,228 : WARNING : All subsystems initialised; now serving
2015-05-02 11:09:32,229 : WARNING : ----------------------------------------
2015-05-02 11:09:34,058 : INFO : REQUEST:INIT-REBOOT from 78:fd:94:c6:17:92 for 
172.29.1.51
2015-05-02 11:09:34,059 : INFO : Dynamic REQUEST:INIT-REBOOT from 
78:fd:94:c6:17:92 for 172.29.1.51 in pool 'legacy-0'
2015-05-02 11:09:34,063 : INFO : Bound 172.29.1.231 to 78:fd:94:c6:17:92 in 
pool 'legacy-0' until Tue May  5 11:09:34 2015
2015-05-02 11:09:34,066 : CRITICAL : Unable to handle REQUEST:INIT-REBOOT from  
78:fd:94:c6:17:92:
Traceback (most recent call last):

  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 391, in wrappedHandler
    f(self, wrapper)

  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 577, in _handleDHCPRequest
    self._handleDHCPRequest_INIT_REBOOT(wrapper)

  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 629, in _handleDHCPRequest_INIT_REBOOT
    definition = wrapper.retrieveDefinition()

  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 375, in retrieveDefinition
    self.pxe and self._pxe_options or None

  File "/etc/staticDHCPd/_handlers.py", line 12, in handleUnknownMAC
    return _dynamic_pool.handle(method, packet, mac, client_ip)

  File "/etc/staticDHCPd/dynamism.py", line 279, in handle
    definition = self._allocate(mac, client_ip)

  File "/etc/staticDHCPd/dynamism.py", line 121, in wrapped_method
    extra=None

TypeError: __init__() got an unexpected keyword argument 'gateway'

I've added the metadata needed by centos, as well as switching to built in 
methods whereever possible.

I've also added the 'status' command, which lets automation tools determine if 
staticDHCPd is running or not (we had issues with Puppet continuously starting 
it due to the lack of the status command).

This should also prevent duplicate instances from being started if you 
repeatedly called the start command.

This will no longer work on debian/ubuntu though, as they don't provide the 
same functions.

I'm trying to get the http extension working with the latest 2.0.0 branch 
(2.0.0-beta-11).

The web server is returning the following json:
{
  "ip": "192.168.100.16",
  "subnet_mask": "255.255.255.0",
  "broadcast_address": "192.168.0.255",
  "gateway": "192.168.100.1",
  "domain_name_servers": ["192.168.100.1"],
  "lease_time": 3600,
  "subnet": "whatever",
  "serial": 0
}

And this yields the following trace:

2014-06-18 09:43:43,780 : CRITICAL : Unable to handle DISCOVER from  
00:0c:29:9a:af:75:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 393, in wrappedHandler
    f(self, wrapper)
  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 503, in _handleDHCPDiscover
    if wrapper.loadDHCPPacket(definition):
  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 341, in loadDHCPPacket
    self._loadDHCPPacket(definition, inform)
  File "/usr/local/lib/python2.7/dist-packages/staticdhcpdlib/dhcp.py", line 321, in _loadDHCPPacket
    self.packet.setOption(6, definition.domain_name_servers)
  File "/usr/local/lib/python2.7/dist-packages/libpydhcpserver/dhcp_types/packet.py", line 549, in setOption
    value = self._extractList(value, option=option)
  File "/usr/local/lib/python2.7/dist-packages/libpydhcpserver/dhcp_types/packet.py", line 378, in _extractList
    'value': value,
TypeError: Value supplied is not a sequence of bytes: [IPv4('192.168.100.1')]

It looks to me like something is going of the rails in the 
setOption/_extraceList method of DHCPPacket but it not really clear to me.
I got this working with 2.0.0-beta-9 (Manually fixing the missing StringTypes 
Reference) so it seems some of the refactorings in between broke stuff.

Let me know if you need additional information.

I think I just noticed a problem with the decoding of the gateway option in 
staticdhcpd.

I'm using the httpdb extension and the backend responds with this json:

{"ip":"10.97.28.194","subnet_mask":"255.255.240.0","broadcast_address":"10.97.31
.255","gateway":"10.97.16.1","domain_name_servers":["10.17.220.80","10.17.122.17
0"],"serial":0,"lease_time":7200}

Using a dhcp test client staticdhcp send the following reply:
Received packet from 10.97.29.190:67:
  op=BOOTREPLY chaddr=00:50:56:BB:03:30 hops=0 xid=A228F507 secs=0 flags=0000
  ciaddr=0.0.0.0 yiaddr=10.97.28.194 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
  9 options:
     53 (DHCP Message Type): offer
     54 (Server Identifier): 0.0.0.0
     51 (IP Address Lease Time): 7200 (2 hours)
      1 (Subnet Mask): 255.255.240.0
      3 (Router Option): 0.0.0.10, 0.0.0.97, 0.0.0.16, 0.0.0.1
      6 (Domain Name Server Option): 10.17.220.80, 10.17.122.170
     28 (Broadcast Address Option): 10.97.31.255

Looks to my like the bytes of the gateway option somehow get split into 
multiple gateway entries somewhere inside staticdhcpd.

Cheers,
Fabian

Hi Neil,

I've downloaded and configured staticdhcpd as instructed for a test setup, but 
it exits with an exception. Not sure if it is a bug or some sort of 
configuration issue. Hope you can help.

I'm running on Linux with Python 2.7.3.

alan@atom:~/Downloads/staticDHCPd-2.0.0-beta-9/staticDHCPd$ sudo ./staticDHCPd 
No handlers could be found for logger "main"
2014-05-06 19:59:17,996 : INFO : Console-based logging online
2014-05-06 19:59:17,997 : WARNING : ----------------------------------------
2014-05-06 19:59:17,997 : WARNING : ----------------------------------------
2014-05-06 19:59:17,997 : WARNING : ----------------------------------------
2014-05-06 19:59:17,998 : WARNING : ----------------------------------------
2014-05-06 19:59:17,998 : WARNING : ----------------------------------------
2014-05-06 19:59:17,998 : WARNING : System startup in progress; PID=5834
2014-05-06 19:59:17,998 : WARNING : staticDHCPd version 2.0.0-beta-7 : 
http://uguu.ca/
2014-05-06 19:59:17,999 : WARNING : libpydhcpserver version 2.0.0-beta : 
http://uguu.ca/
2014-05-06 19:59:17,999 : WARNING : Continuing with subsystem initialisation
2014-05-06 19:59:17,999 : WARNING : ----------------------------------------
2014-05-06 19:59:18,000 : INFO : Webservice module enabled; configuring...
2014-05-06 19:59:18,057 : INFO : Prepared to bind to 0.0.0.0:30880
2014-05-06 19:59:18,059 : INFO : Configured Webservice engine
2014-05-06 19:59:18,060 : INFO : Webservice engine beginning normal operation
2014-05-06 19:59:18,063 : INFO : Webservice logging module enabled; 
configuring...
2014-05-06 19:59:18,064 : INFO : Configuring web-accessible logging...
2014-05-06 19:59:18,064 : INFO : Web-accessible logging online; buffer-size=200
2014-05-06 19:59:18,066 : INFO : Initialising custom code...
2014-05-06 19:59:18,104 : INFO : Prepared to bind to 192.168.123.222; ports: 
server: 67, client: 68, pxe: None
2014-05-06 19:59:18,110 : INFO : Configured DHCP server
2014-05-06 19:59:18,112 : INFO : Changing runtime permissions to UID=1000, 
GID=1000...
2014-05-06 19:59:18,112 : INFO : DHCP engine beginning normal operation
2014-05-06 19:59:18,113 : WARNING : ----------------------------------------
2014-05-06 19:59:18,115 : WARNING : All subsystems initialised; now serving
2014-05-06 19:59:18,115 : WARNING : ----------------------------------------
2014-05-06 19:59:18,117 : CRITICAL : Unhandled exception:
Traceback (most recent call last):
  File "/home/alan/Downloads/staticDHCPd-2.0.0-beta-9/staticDHCPd/staticdhcpdlib/web/server.py", line 315, in run
    self._web_server.handle_request()
  File "/usr/lib/python2.7/SocketServer.py", line 265, in handle_request
    fd_sets = select.select([self], [], [], timeout)
error: (4, 'Interrupted system call')

I've been looking at using the httpdb extension with the latest 2.0.0 branch.

So far I found two minor bugs preventing the use of the extension.
Additionally I took a stab at making the httpdb extension configurable via the 
normal config.py configuration file instead of changed the class attributes in 
the extension itself.

I collected my three changes here: 
https://github.com/databus23/staticdhcpd/pull/1

Cheers,
Fabian

What steps will reproduce the problem?
1.Use IPv6 address wherever required
2.Perform both server and client functions

I defined this trivial loadDHCPPacket function:

def loadDHCPPacket(packet, method, mac, definition, relay_ip, pxe, 
source_packet):
    print source_packet
    return True

and, it crashes with the following exception:

Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/root/staticdhcpd-read-only-2/staticDHCPd/staticdhcpdlib/dhcp.py", line 391, in wrappedHandler
    f(self, wrapper)
  File "/root/staticdhcpd-read-only-2/staticDHCPd/staticdhcpdlib/dhcp.py", line 498, in _handleDHCPDiscover
    if wrapper.loadDHCPPacket(definition):
  File "/root/staticdhcpd-read-only-2/staticDHCPd/staticdhcpdlib/dhcp.py", line 346, in loadDHCPPacket
    self._original_packet
  File "/root/staticdhcpd-read-only-2/staticDHCPd/conf/conf.py", line 224, in loadDHCPPacket
    print source_packet
  File "/root/staticdhcpd-read-only-2/staticDHCPd/libpydhcpserver/dhcp_types/packet.py", line 1028, in __str__
    } for id in self.getSelectedOptions())
  File "/root/staticdhcpd-read-only-2/staticDHCPd/libpydhcpserver/dhcp_types/packet.py", line 1028, in <genexpr>
    } for id in self.getSelectedOptions())
KeyError: 175


As a reminder, the iPXE boot packet looks like this:

14:53:06.602518 IP (tos 0x0, ttl 64, id 1821, offset 0, flags [none], proto UDP 
(17), length 427)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:9e:be:28, length 399, xid 0x65eea51e, secs 12, Flags [none] (0x0000)
          Client-Ethernet-Address 52:54:00:9e:be:28
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            MSZ Option 57, length 2: 1472
            ARCH Option 93, length 2: 0
            NDI Option 94, length 3: 1.2.1
            Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
            CLASS Option 77, length 4: "iPXE"
            Parameter-Request Option 55, length 22:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, LOG
              Hostname, Domain-Name, RP, Vendor-Option
              Vendor-Class, TFTP, BF, Option 119
              Option 128, Option 129, Option 130, Option 131
              Option 132, Option 133, Option 134, Option 135
              Option 175, Option 203
            T175 Option 175, length 48: 



This seems to originate from DHCP_OPTIONS not having a setting for option 175.  
I'm not sure if a better solution is to just add it (which is what I did), or 
handle unknown IDs better.