DHCP responses not coming from the correct port about staticdhcpd

[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 [email protected] 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 [email protected] 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