[Dnsmasq-discuss] possible Bug: DHCPDISCOVER no address available

[Simon Kelley]

On 23/05/13 08:14, Thomas Kärgel wrote:
> Hi everyone,
>
> Thanks for the wonderful work you did in this project. i'm using dnsmasq
> for years now and never had any problems with it until now. I hope that
> someone can help us with this problem or at least help us pointing out
> what the cause of this problem is. Many thanks in advance.
>
>   Dnsmasq is used as DHCP-Server in Openstack Cloud Software. The normal
> usage principle looks like this:
>
> 1. An Openstack service starts dnsmasq as DHCP-daemon configured with
> "--dhcp-hostsfile=filename"-option. The hostsfile is written by
> openstack and filled with information in dnsmasq-format.
> Example:
> fa:16:3e:86:19:a6,,10.72.226.10,172800
> fa:16:3e:78:19:8b,,10.72.226.11,172800
                     ^

double comma? I didn't consider that a possibilty when writing the 
parsing code. It probably works, but worth a try removing this.
>
> 2. everytime a new entry is added or removed in the hostsfile dnsmasq
> gets signal HUP sent by Openstack, so that it re-reads its configs and
> hostfile. After that dnsmasq is aware of the mac-address/IP-pair and can
> deliver the IP when the client performs DHCP-Discover.
>
> The above mechanism is working fine in most cases. But lately there were
> a few reports (4 afaik) that this mechanism is not working entirely
> reliable.
> Dnsmasq re-reads it's configs but still claims that no address is
> available for the specific mac-address, while other clients are still
> receiving their adresses fine.
> The new entries in hostsfile do not get served until dnsmasq is killed
> and restarted.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This might be significant, since the process on re-read a hostfile is

1) Throw away all entries which came from a hostsfile in the past.
2) Read the hostsfile and insert all the entries found there.

It's difficult to see how that process could distinguish between new and 
old entries except if some hosts already have leases. Can you Explore 
this a bit more? Maybe release a DHCP lease on an old host, and then see 
if it can get a lease back again?


>
> Things i checked so far:
> -new hostsfile is completely written to disk at the time dnsmasq gets
> signal HUP.
> -no firewall rules or whatever interfere the communication between
> dnsmasq and its client.
> -manually sigHUPing dnsmasq has no effect. Dnsmasq logs that it has
> re-read config files including hostsfile.
> -concerned entries in hostsfile are valid (and work as soon as dnsmasq
> is killed and restarted)
>
> Details:
>
> Used dnsmasq version is 2.59. The issue was recognized on Ubuntu
> 12.04LTS and SLES11SP2 systems. Upgrading to dnsmasq 2.66 had no effect.
> The issue still occurs.
>
> Dnsmasq is started with the following parameters in my openstack
> environment. (This may look slightly different on other environments):
> ps aux|grep dnsmasq
> dnsmasq   8123  0.0  0.0  11112  1036 ?        S    May10   8:39
> /usr/sbin/dnsmasq --log-dhcp --no-hosts --no-resolv --filterwin2k
> --strict-order --bind-interfaces --interface=ns-606c17e0-c3
> --except-interface=lo --domain=openstacklocal
> --pid-file=/var/lib/quantum/dhcp/e4d06a35-c14c-4102-88bc-4be760927b94/pid --dhcp-lease-max=2000
> --dhcp-hostsfile=/var/lib/quantum/dhcp/e4d06a35-c14c-4102-88bc-4be760927b94/host
> --dhcp-optsfile=/var/lib/quantum/dhcp/e4d06a35-c14c-4102-88bc-4be760927b94/opts
> --dhcp-script=/usr/bin/quantum-dhcp-agent-dnsmasq-lease-update
> --leasefile-ro --dhcp-range=set:tag0,10.72.0.0,static
>
> There is a thread on openstack mailing-list that describes this behavior
> in all details:
> https://lists.launchpad.net/openstack/msg23817.html
> Most of the information there is openstack specific. I think it is of no
> interest here.
>
> An excerpt of relevant log entries looks like this:
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> May 20 09:04:34 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> available
> May 20 09:04:52 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> available


This is definitely "static address only on this network, unknown host"


It may be worth setting --log-dhcp for the extra information that can 
give us.



Cheers,

Simon.

>
>
> Best regards,
> Thomas
>
>
>
>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss