[Dnsmasq-discuss] Always Ignore Client Identifier
Linux Luser
linuxluser at gmail.com
Sat Feb 8 17:42:04 GMT 2014
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).)
FYI, I'm using version 2.59 (comes with Debian wheezy). Thanks for any help!
On Fri, Jan 31, 2014 at 1:48 PM, Simon Kelley <simon at thekelleys.org.uk>wrote:
> On 31/01/14 16:25, Linux Luser wrote:
>
>> dhcp-ignore-names is concerned about the hostname, correct? I am
>> interested in the client identifier option sent in the DHCPREQUEST.
>> Ignoring this field would break RCF2131 (and probably some people's
>> networks!) but in my particular case, it may spare me some problems.
>>
>
> I understand, I'm proposing a new option, dhcp-ignore-clid, analogous to
> the existing dhcp-ignore-names.
>
>
>
>> Maybe if I could selectively revoke leases, that would work. Could I do
>> this? I'm sure that dnsmasq keeps an internal cache, so that would have
>> to be flushed for a particular lease.
>>
>
> There is a utility in contrib/wrt in the source distribution, and a binary
> in the Debiann package of dnsmasq, for releasing a specific lease from the
> command-line.
>
>
>> On Jan 30, 2014 2:08 AM, "Simon Kelley" <simon at thekelleys.org.uk
>> <mailto:simon at thekelleys.org.uk>> wrote:
>>
>> On 29/01/14 18:04, Linux Luser wrote:
>>
>> We have a pretty tightly-controlled private network environment
>> which
>> we've configured to have a 1-to-1-to-1 relationship between
>> client MAC
>> address, hostnames and IP addresses. Apart from "guest" IP
>> ranges, we
>> have control over when clients get added to the network. Thus,
>> we can
>> detect duplicate MAC addresses before it becomes an issue.
>>
>> In this setup, we can't need or want to use the "client
>> identifier"
>> option of DHCP. In fact, it becomes a problem when we start doing
>> PXELinux installs, where a different client id gets sets during
>> a remote
>> install session, then when the install is complete and the new
>> OS boots
>> up, it gets a different IP address (because dnsmasq still knows
>> about
>> the lease it gave that same machine only 10 minutes ago!).
>>
>> To get rid of this issue, we now supply a dhcp-host option to
>> dnsmasq
>> each time we want to do a remote reinstall. The option looks
>> something
>> like this:
>> dhcp-host=<MAC addr>,id:*,<hostname>,<IP addr>,set:install
>>
>> This works, since the "id:*" part tells dnsmasq to ignore the
>> client ID
>> in favor of the MAC address. But now to my question. Can this be
>> done
>> for ALL DHCP requests? Is there a global "identify-by-mac-only"
>> option?
>> If not, would you be willing to entertain the idea. I know many
>> others
>> have done this for some time now, using other DHCP server
>> software, so I
>> know it's possible and there doesn't seem to be any ill effects
>> of this.#
>>
>>
>> There isn't a global option to do this, but there is precedent, in
>> the form of --dhcp-ignore-names for adding it, and actually that's
>> something more useful, since the tag system allows the setting to be
>> applied to classes of clients (which could, of course, be "all
>> clients")
>>
>>
>> Maybe this is not a good idea? Like I said, we have a fairly
>> controlled
>> environment, so it would work for us. I could see how this would
>> be
>> unnecessary for common setups, though. Or environments that have
>> many
>> VMs running on a single host and simply bridge their network
>> interface
>> may want to use the "client identifier" option so each VM gets a
>> unique
>> IP even if they're running on the same machine or t But it would
>> be nice to
>> have a greater level of control over this.
>>
>>
>> Thanks for your time. And GREAT piece of software, by the way.
>> dnsmasq
>> is a HUGE time saver and makes changing configurations
>> straight-forward.
>> Do you accept donations? :)
>>
>>
>> Donations by Paypal to simon at thekelleys.org.uk
>> <mailto:simon at thekelleys.org.uk> are always welcome, or you could
>>
>> commission me to add new features. I'm available for that on a
>> consultancy basis, cheaper for stuff which goes back into the
>> dnsmasq GPL codebase, more expensive for proprietary code.
>>
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>> --
>> daV.e
>>
>>
>> _________________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.__thekelleys.org.uk
>> <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
>> http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__
>> discuss
>> <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
>>
>>
>>
>> _________________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.__thekelleys.org.uk
>> <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
>> http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__discuss
>> <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
>>
>>
>
--
daV.e
"The reasonable man adapts himself to the conditions that surround him...
The unreasonable man adapts surrounding conditions to himself... All
progress depends on the unreasonable man." Bernard Shaw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20140208/bcdf078b/attachment.html>
More information about the Dnsmasq-discuss
mailing list