Closed icb- closed 10 years ago
I can code up either of these options. I'm looking for input on which is preferred. The later could be implemented by adding a broadcast
argument that can be set to either the current '<broadcast>'
, 255.255.255.255
, or the subnet broadcast as needed.
-s should let you choose a source ip, thereby the interface. Does this not work as I think it should?
If not, I would prefer to stick to the RFC
ah, it doesn't. I'm unable to change the code at the moment. I think if the bind inside the init for dhcpd is told to use self.ip rather than '', -s will let you use an interface
Binding to the interface address, rather than to the wildcard, doesn't work. The packets aren't received.
That isn't ideal. Probably the most portable method would be your second suggestion, having an argument that allows you to specify the broadcast for dhcp. It would need to be noted that this is against the rfc.
Does the rfc mention how to handle this problem?
I've not seen it in the RFC. I've looked through the ISC DHCP server documentation, and they have a number of OS-specific workarounds. SO_BINDTODEVICE is one of them. Others include the Linux Packet Filter, and using raw sockets. Another option appears to be adding a route to 255.255.255.255
in the OS out the correct interface.
Adding a route could break other programs.
Raw sockets means we have to do our own ip and udp as well. And we have to do our own receive filter.
I think os workarounds, or completely swapping out all network code for something like scapy, but then we have external dependencies.
I would avoid external dependencies like the plague, if we can do it without them then all the better. One of my favorite things about this project is that it requires no external dependencies and, because of that, is very portable.
When serving DHCP on CentOS 6, DHCP replies are only sent out the first interface.
I've tested two options, both of which work for me in testing with iPXE.