Changing output from error to info

Simon Hobson dhcp1 at thehobsons.co.uk
Mon Nov 10 21:25:44 UTC 2014


Peter Rathlev <peter at rathlev.dk> wrote:

> One might consider the method of placing an empty subnet declaration
> somewhere in the configuration file a litte odd, but it aligns well with
> the general advice to remember letting the DHCP server know what the
> network looks like.
> 
> If you want alignment between the syslog priority and what actually
> happens then it could be an equally good solution to just let dhcpd die
> on such an error. :-)

Which is more or less what I hinted at earlier.
IMO, if you don't tell the server which interfaces to listen on, then the assumption should be that you want it to listen on all of them. In that case, if there isn't a subnet to go with an interface then that's an error.


Shawn Routhier <sar at isc.org> wrote:

> The problem we would solve is to more properly align the message groupings.
> So somebody who doesn't want to see these in their syslog would be able to avoid
> them.

You can already avoid having them in your syslog - just properly configure your server and you won't see the message. If you see the message, then the server isn't properly configured.



Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> I would rather the stupid pcap-based interface stuff died altogether. I've lost count of the number of times it's made me want to smash my keyboard in frustration.
> 
> "Want to answer a DHCP request on a GRE tunnel? Too bad, loser!"

Actually it is possible. If you disable the right feature during compile time then I believe you can handle requests via arbitrary interfaces (anything with an IP address). *BUT* you then lose the ability to handle locally connected clients which is what the raw sockets stuff is about.
A bit of history might make is seem less of a "WTF were they thinking ?" feature. The ISC server has been around "a long time", back to the days when SLIP and Token Ring were about the only non-Ethernet interfaces around. Given the need to handle packets from clients without an IP address - which precludes using the hosts network stack - then handling raw packets (with the limitations you've observed) makes sense.
Since then things have moved along, but no-one has stepped up and either a) offered to write the new code for free, or b) sponsor having it written. I guess it probably needs code adding to only try to do the raw packet stuff on "ethernet like" interfaces".

Of course, you can complain about the missing feature without doing anything about it ...





More information about the dhcp-users mailing list