[Dnsmasq-discuss] dhcp not working

[Schley Andrew Kutz]

Simon,

Okay. It doesn't appear to be the IP tables, but I did some digging.  
If I run tcpdump on the host I get:

[0]akutz at legacy:~$ sudo tcpdump -ni en1 'udp port 67 and udp port 68'
tcpdump: verbose output suppressed, use -v or -vv for full protocol  
decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:57:16.591186 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,  
Request from 00:18:8b:3e:29:3c, length 272
14:57:32.873143 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,  
Request from 00:23:df:58:53:3a, length 300
14:57:32.879882 IP 172.25.0.2.67 > 255.255.255.255.68: BOOTP/DHCP,  
Reply, length 303
14:58:20.489057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,  
Request from 00:18:8b:3e:29:3c, length 272
^C
4 packets captured
1086 packets received by filter
0 packets dropped by kernel

So it appears as if the VM's NIC, (coming from 0.0.0.0.68) is sending  
a DHCP request to the broadcast address of the host's subnet and  
getting a response from the DHCP server on the host's subnet, not the  
DHCP server included with dnsmasq. I can verify this by looking at the  
logs in the VM (OpenSUSE 11) in /var/log/messages. This line appears  
over and over again:

linux dhclient; DHCPDISCOVER on eth0 to 255.255.255.255 port 67  
interval x

I would think that this is a fairly normal set up, so what am I doing  
incorrectly that the dnsmasq server isn't catching the DHCP request?  
For completeness, here is the output from dnsmasq:

[130]akutz at legacy:src$ sudo ./dnsmasq -a 192.168.3.1 -b -f -F   
192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l /opt/ 
akin/dnsmasq.leases -d
dnsmasq: started, version 2.49 cachesize 150
dnsmasq: compile time options: IPv6 no-GNU-getopt no-DBus no-I18N DHCP  
TFTP
dnsmasq: setting --bind-interfaces option because of OS limitations
dnsmasq-dhcp: DHCP, IP range 192.168.3.15 -- 192.168.3.254, lease time  
1h
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 172.16.100.250#53
dnsmasq: using nameserver 172.25.0.2#53
dnsmasq: read /etc/hosts - 5 addresses
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92

Thanks!

-- 
-a

"Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former." -- Einstein

On Aug 27, 2009, at 10:53 AM, Simon Kelley wrote:

> Schley Andrew Kutz wrote:
>> I am attempting to use dnsmasq to more fully supply functionality  
>> for  my own project, akin (http://akutz.wordpress.com/2009/08/20/building-a-better-os-x-firewall-or-how-i-solved-the-nat-problem-for-virtualbox 
>>  ). The DNS portion is working great, but DHCP requests are stuck  
>> in an  endless loop of DISCOVER,OFFER.
>> The options I use are:
>> sudo ./dnsmasq -a 192.168.3.1 -b -f -F   
>> 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l / 
>> opt/ akin/dnsmasq.leases -d
>> I thought it might be an IP tables issue, but I set my deny rule  
>> to  log and no packets are getting dropped. Besides, I have a  
>> static  allowance for all traffic on the virtual interface that dns  
>> masq is  operating on.
>> Thoughts?
>
>
> Look at the logs on the clients to see if they are getting the  
> OFFERs. If not look again at iptables.
>
> Simon.
>
>