[Dnsmasq-discuss] Dnsmasq wont recieve DHCP request messaegs

2014-02-08 Thread Kiazada Dany-GVN438
Hi,

I'm using the program as a DHCP server for a Linux machine. The server needs to 
toggle between two different subnets, with different GW (on the same interface 
- 'br0'), and assign an IP for a windows PC.
So for example upon power up the DHCP will assign an IP to the PC (connected 
via Ethernet), with subnet 'A'.
After a while, the DHCP will need to assign a different IP, on a different 
subnet 'B'.
The way I implemented it is running dnsmasq on the Linux machine :

 -C /etc/dnsmasq.conf/sbin/dnsmasq -d --clear-on-rel

With The following  dnsmask.conf file (subnet 'A') :

dhcp-range=27.187.20.14,27.187.20.14,255.255.255.0,3600
interface=br0
dhcp-option=3,27.187.20.1
dhcp-option=6,27.187.20.1
dhcp-leasefile=/etc/dnsmasq.leases
dhcp-lease-max=253
log-dhcp

After I receive an indication to change the subnet, I kill the dnsmasq server, 
and run it again the same way only with the second subnet 'B'.
I noticed that the dnsmasq.leases is empty, and there are no connected clients 
after the second power up. The PC is sending DHCPINFORM messages (with no 
response) and
In order to have the PC ask for a new IP, I cut the power to the Ethernet 
Iface. This causing the PC to send DHCPREQUEST messages (with no DISCOVER 
messages before).
The dnsmasq is not responding to the REQUEST messages although it's a broadcast 
message, and I can see at tcpdump that they arrive to the Linux machine...

I can see in the app logs that the dnsmask is receiving the INFORM messages, 
but I cannot see the REQUEST messages (in the app logs).
The thing is the PC remembers the first IP it was assigned (subnet 'A'),  and 
although the DHCP server has a different IP range configuration, the PC is 
still showing the old IP.

So my goal is to have the PC assigned a new IP (without any PC involvement, 
meaning no ipconfig renew\release commands). from a different pool, different 
subnet and GW, after the dnsmasq is restarted.

Thank,
Dany

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


[Dnsmasq-discuss] I love this little gem !

2014-02-08 Thread Elsie Buck
I just ran across
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q1/008009.htmlwhich
is exactly what I want to do at my home. Why you ask? Well, I have 5
computers (one for each room), 2 file servers, 2 media players and 2
laptops. Not real impressive, but DNSMasq setup correctly, blocks banner
ads and bad sites (yeah I get the lists from a couple of places - it's all
automatic to me). so the "bad" sites get sent to my own web server which
basically says "Oops, you didn't intend to be here". Which is ok. I know
what it means and why I ended up there. I'm the only one who counts. What I
don't want is the boring "site not found" (NXDomain). I thought I knew
where that page was generated from within windows, but I cannot remember
and Google just isn't helping. So I thought, how about DNSMasq? But the
above link explains why not. I'm running DNSMasq on a DNS-323 "file
server". I believe I've found other programs that might do something close
to what I want, but I don't know those programs and would rather stay with
the tried and true. I thought if enough people requested this feature, you
might reconsider...

Did I tell you, I love this little gem? dhcp is fantastic. I have 10
devices that can be configured simply with DNSMasq. How cool is that?
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Execute external script on DNS resolution

2014-02-08 Thread Francois Prowse
Looking at Dnsmasq and there is the ability to execute an external script
when an address is allocated through DHCP, or it expires.

Is it possible to execute a script when a client resolves an address? This
would probably be a bit more complicated than the DHCP example due to
multiple returned addresses etc. I'd like to be able to pass the client's
IP address, the requested domain and the resolved IP addresses to an
external script if possible.

Any help appreciated.

Cheers

Francois
___
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

2014-02-08 Thread Linux Luser
Correction: I'm "getting wildly different IP addresses" not "wildly
different MAC addresses."


On Sat, Feb 8, 2014 at 9:42 AM, 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).)
>
>
> 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 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" >> > 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, w

Re: [Dnsmasq-discuss] Always Ignore Client Identifier

2014-02-08 Thread 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!



On Fri, Jan 31, 2014 at 1:48 PM, Simon Kelley 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" > > 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=,id:*,,,set:install
>>
>> This works, since the "id:*" part tells dnsmasq to ignore the
>> client ID
>> in favor of th

Re: [Dnsmasq-discuss] Testers wanted: DNSSEC.

2014-02-08 Thread Eugene Rudoy
Hi Simon,

On Thu, Feb 6, 2014 at 11:29 AM, Simon Kelley  wrote:
>
> What result do you get if you run
>
> dig +dnssec @8.8.8,8 ietf.org
>
> It's not unknown for an ISP to redirect all port 53 traffic to their own DNS
> servers.

you're right, it seems my ISP redirects all port 53 traffic...

This is the answer I get if I run "dig +dnssec @8.8.8.8 ietf.org"
while connected through my ISP:

; <<>> DiG 9.8.1-P1 <<>> +dnssec @8.8.8.8 ietf.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11422
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;ietf.org. IN A

;; ANSWER SECTION:
ietf.org. 1407 IN A 4.31.198.44

;; Query time: 50 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Feb  8 10:55:23 2014
;; MSG SIZE  rcvd: 53

This is the answer to the same query while using ISP of my father:
; <<>> DiG 9.8.1-P1 <<>> +dnssec @8.8.8.8 ietf.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40854
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;ietf.org. IN A

;; ANSWER SECTION:
ietf.org. 1799 IN A 4.31.198.44
ietf.org. 1799 IN RRSIG A 5 2 1800 20150203200914 20140203191110 40452
ietf.org. LaMW5WtE2HErWUlDRJGZeDiP0CiMIXB3Dcy5phPIT4v0pEf6FG8hAM5V
8pL8T38jovBPrMzRqqMO9VJspXKrs2UTefHl6Gkyn7rPjHYzusBQyvXm
Gzy8uI46CIGQ7DKZYhU7LTDl4Xd7CI+xbqSL1jUXvSFVnTxgRJ5nhmBM
wd1+KFV9zgAviOZW3kd7NiOgKRIrdQHtojE/LgBwAiejm6snmYte/bqc
LV+d/UUnwx7PRQlr0cXS1U5fpYbLCMI0q7Pj63CDQqMbI+R9SlSlKPFB
9pK73sJ7KMyinZT8TDbLvfbbywGfRwcOZs290aqjIycEh7t18K48vslD OZ5McQ==

;; Query time: 144 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Feb  8 10:57:16 2014
;; MSG SIZE  rcvd: 349

I'll ask my ISP if they can disable this "feature"...

Thanks!

Best regards,
Gene

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