[Dnsmasq-discuss] Always Ignore Client Identifier

Linux Luser linuxluser at gmail.com
Tue Feb 11 17:03:02 GMT 2014


That makes sense. I may just do that. Since /etc/ethers and
/etc/dnsmasq-hosts.d would both be reread upon a SIGHUP signal, it seems
that there wouldn't be much of a difference either way, other than, as you
say, one way is more confusing than another.

Thanks again!
On Feb 11, 2014 5:36 AM, "Simon Kelley" <simon at thekelleys.org.uk> wrote:

> On 08/02/14 17:42, Linux Luser wrote:
>
>> dhcp-ignore-clid might just work for the long-term. But I ended up
>> playing around a bit more and I've managed to isolate the part of my
>> config that I believe triggers the problem. Maybe this can be fixed
>> without a dhcp-ignore-clid option?
>>
>> When I set a host's MAC address and IP association in /etc/ethers (with
>> the read-ethers option on of course) and that same host's IP address to
>> hostname association in /etc/hosts, I am able to get a consistent IP,
>> whether or not that same host is using PXE boot, the Debian installer
>> (where it send the vendor-id as "d-i", which shouldn't matter in this
>> case) or boots to its own image on the drive. It is consistent, that is,
>> until I implement a "trick" that I wanted to use so I could whitelist
>> hosts for PXEboot. That's when it got inconsistent and I would end up
>> with a brand new IP address for PXE and usually another brand new one
>> when the host boot into it's own OS. I could only get the IP that I had
>> set in /etc/ethers if I restarted dnsmasq on the server. Otherwise the
>> host would receive the same WRONG IP over and over for each renewal.
>>
>> Here's the config I had BEFORE implementing a "PXEboot whitelist":
>>
>> domain-needed
>> bogus-priv
>> log-dhcp
>>
>> domain=mydomain
>> local=/mydomain/
>> server=8.8.8.8
>> server=8.8.4.4
>>
>> interface=eth0
>> except-interface=eth1
>>
>> expand-hosts
>> read-ethers
>>
>> dhcp-range=tag:known,set:controller,10.1.0.1,10.1.255.254,2h
>> dhcp-range=tag:known,set:device,10.2.0.1,10.2.255.254,2h
>> dhcp-option=option:router,10.0.0.1
>>
>> enable-tftp
>> tftp-root=/tftpboot
>> dhcp-boot=pxelinux.0
>>
>>
>> Now, I'll add the lines which allow me to use a directory of files for
>> dhcp-host commands:
>>
>> dhcp-vendorclass=pxe,PXEClient
>> dhcp-ignore=tag:pxe,tag:!install
>> dhcp-hostsfile=/etc/dnsmasq-hosts.d
>>
>>
>> Inside of /etc/dnsmasq-hosts.d then I can put files that contain lines
>> like this one:
>>
>> 01:02:03:04:05:06,set:install
>>
>> ... and send a SIGHUP to dnsmasq process. After this, the host with that
>> MAC address gets the tag "install" and instead of ignoring PXEboot,
>> dnsmasq will respond for that host. Wonderful! Problem: now I'm getting
>> wildly different MAC addresses. It's like dnsmasq is reading the files
>> in /etc/dnsmasq-hosts.d and ignoring the /etc/ethers file. Is this
>> expected behavior? A bug? I know that specifying a DIRECTORY instead of
>> a file for the dhcp-hostsfile is kind of a new feature. (For my
>> purposes, I'd prefer a directory because it's possible that several
>> processes might want to write files at the same time. It's easy to avoid
>> concurrency problems by putting files with unique names in a directory
>> (named after MAC or hostname or UUIDs, etc).)
>>
>>
>>
> My guess is that dnsmasq is failing to integrate the information from
> /etc/ethers and the dnsmasq-host.d file into a single coherent record.
> There are various heuristics in the code to do that for common situations,
> but since there no real "primary key", it difficult to do it generally. Do
> you merge the settings for a MAC address. for and IP address, for a
> hostname?
>
> The simplest solution is probably to abandon /etc/ethers, and put all the
> information in one place in the files in /etc/dnsmasq-hosts.d  It;s fine to
> keep what you have and add IP addresses and/or hostnames to that.
>
>  01:02:03:04:05:06,set:install,1.2.3.4
>
> Cheers,
>
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20140211/d1a69306/attachment.html>


More information about the Dnsmasq-discuss mailing list