[Dnsmasq-discuss] Always Ignore Client Identifier

[Linux Luser]

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.

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. 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? :)

[Simon Kelley]

Post by Linux Luser
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
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")

Post by Linux Luser
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 ***@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.

Post by Linux Luser
--
daV.e
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Linux Luser]

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.

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.

Post by Simon Kelley

Post by Linux Luser
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
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")

Post by Linux Luser
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? :)

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.

Post by Linux Luser
--
daV.e
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Simon Kelley]

Post by Linux Luser
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.

Post by Linux Luser
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.

Post by Linux Luser
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
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? :)
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
http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__discuss
<http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
_________________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__discuss
<http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>

[Linux Luser]

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!

Post by Simon Kelley

Post by Linux Luser
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.

Post by Linux Luser
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.

Post by Linux Luser
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
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? :)
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
http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__
discuss
<http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
_________________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__discuss
<http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>

[Linux Luser]

Correction: I'm "getting wildly different IP addresses" not "wildly
different MAC addresses."

Post by Linux Luser
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.
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-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
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!

Post by Simon Kelley

Post by Linux Luser
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.

Post by Linux Luser
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.

Post by Linux Luser
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
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? :)
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
http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__
discuss
<http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_________________________________________________
Dnsmasq-discuss mailing list
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

[Simon Kelley]

Post by Linux Luser
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.
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-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
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

[Linux Luser]

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!

Post by Simon Kelley

Post by Linux Luser
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.
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-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
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