[Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain

Anand Kameswaran akameswaran at gmail.com
Sat Jul 18 15:22:14 BST 2009

I got dhcp-helper 0.7.1 from debian etch installed.  Sarge aparently did not
come with it, and when I try running a 1.0 version I get a segfault.  So for
the moment I'm using the 0.7.1

What is the difference between -i and -e?  I have tried binding to every
interface, and I am sending the -s to an IP Address that is pingable (It
does go over the tunnel interface to reach there)  However, so far as I can
tell nothing is happening.  Without ethereal, I'm not sure how to debug
which step is failing, but I would have expected DNSMasq to at least serve a
dhcp address, even if incorrectly.

Something else is it appears that broadcast over GRE tunnels is not possible
in 2.4 kernel.  I've found some things on how to do it in 2.6, but not 2.4
I'm going to do more research

On Fri, Jul 17, 2009 at 9:21 AM, Simon Kelley <simon at thekelleys.org.uk>wrote:

> Anand Kameswaran wrote:
>> Maybe this is a lot more straightforward than I am thinking, but I'm not
>> sure how I should configure DHCP, once I start using DHCP helper.
>> Let me try and explain the setup.  Each embedded device has 2 physical NIC
>> cards.  Eth0 and Eth1.  Eth0 is used for public communincations and the VPN
>> tunnels are setup between the two devices eth0 interfaces.  Eth1 had
>> multiple virtual adapters to handle the subnetting, ie. eth1:1...eth1:n
>>  depending on the number of required subnets.
>> Now when configuring DNSMasq I had run into an oddity.  The machines
>> absolutely should not provide DHCP over eth0 as that would impact the public
>> network.  Initially I configured dnsmasq to explicitly listen on all eth1.x
>> interfaces, but it didn't work.  However, when I configured dnsmasq to only
>> exclude eth0 everything worked fine.
>> Here is the crux of the problem using dhcp_helper.  So device 1 is
>> providing DHCP/DNS.  I need to assign a different subnet for nodes on device
>> 2 than for device 1, so that routing can occur over the tunnels.  Obviously
>> each side of the vpn tunnels needs unique subnets.  That is one problem,
>> although I know dnsmasq can serve up addresses in multiple ranges.  The real
>> problem I suspect is that requests from nodes on device two, sent over
>> broadcast will probably be received physically on eth0.  ALthough their is
>> in fact a "tunnel" device as well.  (btw using GRE tunnels for the VPN - not
>> encrypted as I am only concerned about network segregation not security)
>> Now I'm not really a good networking guy - so forgive me if my terminology
>> is slightly off, but hopefully my problem is clear.  And I am not really to
>> clear on how to configure dnsmasq once I have DHCP helper working.  I need
>> those requests that come over the DHCP_Helper to get a different subnet.
>>  Any suggestions?
>> Cheers,
>> AK
> You're worrying too much. It all happens automagically. Set up dhcp-helper
> to listen for broadcasts on the correct interface and bounce them to
> dnsmasq. When dhcp-helper does this, it puts the address of the interface on
> which the broadcast was received into the packet, in the giaddr field. When
> dnsmasq gets a packet with giaddr set, it uses that address to decide which
> subnet to allocate an address on, not the interface that dnsmasq received
> the packet on.
> So:
> dnsmasq, just list all the subnets you will need as dhcp-ranges.
> dhcp-helper, select the interfaces  to listen for broadcasts using -i
> <interface> and/or -e <interface> and tell dhcp-helper where to send the
> packets to with -s <ip-addr of server running dnsmasq>
> If the dnsmasq server is multi-homed you can use any of its addresses, as
> long as they are routable from the relay. The address of any interface that
> dhcp-helper is listening on must be routable from the host running dnsmasq.
> Simon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090718/e501fcf2/attachment.htm 

More information about the Dnsmasq-discuss mailing list