Re: [Dnsmasq-discuss] Always Ignore Client Identifier
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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Always Ignore Client Identifier
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 si...@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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Always Ignore Client Identifier
Correction: I'm getting wildly different IP addresses not wildly different MAC addresses. On Sat, Feb 8, 2014 at 9:42 AM, Linux Luser linuxlu...@gmail.com 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).) 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 si...@thekelleys.org.ukwrote: 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 si...@thekelleys.org.uk mailto:si...@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:
Re: [Dnsmasq-discuss] Always Ignore Client Identifier
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. On Jan 30, 2014 2:08 AM, Simon Kelley si...@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 si...@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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Always Ignore Client Identifier
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 si...@thekelleys.org.uk mailto:si...@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 si...@thekelleys.org.uk mailto:si...@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@lists.__thekelleys.org.uk mailto:Dnsmasq-discuss@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@lists.__thekelleys.org.uk mailto:Dnsmasq-discuss@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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Always Ignore Client Identifier
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 si...@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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Always Ignore Client Identifier
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? :) -- daV.e ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss