DHCP responses not coming from the correct port

[GoogleCodeExporter]

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

Original issue reported on code.google.com by d...@devicenull.org on 8 Jul 2014 at 2:47

[GoogleCodeExporter]

That should be the purpose of the two options described here: 
http://static.uguu.ca/projects/staticDHCPd/doc/customisation/configuration.html#
dhcp-server-port-integer-default-67

However, I cannot recall, right now, whether it handles the two ports being the 
same. I'll look at the code as soon as I can and make any necessary changes to 
deal with that case, possibly making 67 the default before 2.0.0-rc1, if 
research shows that it helps in more situations than it would hurt.

Thanks for reporting this!

Original comment by red.hamsterx on 8 Jul 2014 at 3:07

• Changed state: Accepted

[GoogleCodeExporter]

I have both of those set as the default, which should be the correct behavior:

#The port on which DHCP requests are to be received; 67 is the standard.
DHCP_SERVER_PORT = 67
#The port on which clients wait for DHCP responses; 68 is the standard.
DHCP_CLIENT_PORT = 68

The problem is, even with these set I'm seeing responses from a random high UDP 
port instead:

10:32:38.262401 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request 
from 52:54:00:59:54:85, length 399
10:32:38.263467 IP 216.x.x.251.43777 > 255.255.255.255.bootpc: BOOTP/DHCP, 
Reply, length 343

I don't think making those the same would help, this seems to be related to 
using a different socket for _response_socket.

Original comment by d...@devicenull.org on 8 Jul 2014 at 3:14

[GoogleCodeExporter]

Yeah, I thought I had _response_socket binding to whatever was set as the 
client-response socket.

Unfortunately, I'm at work right now, so my ability to investigate code-flows 
is a bit limited. I should have something committed in a few hours, though, 
once I can take a short break.

Original comment by red.hamsterx on 8 Jul 2014 at 3:17

[GoogleCodeExporter]

Looking at the code, it seems like what you're using is what's in Trunk, which 
would be 1.6.4.

2.0.0 has a completely reworked packet-management framework that looks like it 
should be doing the right thing with ports, giving you 67 by default.

2.0.0 is also meant to be entirely backwards-compatible with 1.x's 
configuration/scripting, so you should be able to just drop it in place or copy 
your config, then use svn switch.

I'll leave this issue open as a reminder to fix it in 1.6.x, for correctness's 
sake, but I think the problem has been resolved in the active branch.

-Neil

Original comment by red.hamsterx on 9 Jul 2014 at 12:00

[GoogleCodeExporter]

Initially, I was seeing the following with 2.0.0

15:19:46.660708 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request 
from 52:54:00:9e:be:28, length 399
15:19:46.662368 IP 169.254.169.254.56315 > 255.255.255.255.bootpc: BOOTP/DHCP, 
Reply, length 327
15:19:46.663982 IP 169.254.169.254.56315 > 255.255.255.255.bootpc: BOOTP/DHCP, 
Reply, length 327

The server listens on:

python  15827 nobody    4u  IPv4 309215426      0t0     UDP *:bootps
python  15827 nobody    5u  IPv4 309215429      0t0     UDP *:41370
python  15827 nobody    6u  IPv4 309215431      0t0     UDP 
169.254.169.254:56315

(Note that the server is explicitly configured to use 169.254.169.254 as a 
response address here, so that part at least is correct).


I then discovered the DHCP_RESPONSE_INTERFACE configuration option.  Once I set 
that to my outbound interface, I started seeing the correct behavior.  So yes, 
this is resolved with 2.0.0

Original comment by d...@devicenull.org on 3 Oct 2014 at 7:36

[GoogleCodeExporter]

Finally have time to work on projects again, so marking this as closed.

Original comment by red.hamsterx on 21 Mar 2015 at 3:08

• Changed state: Verified