[Dnsmasq-discuss] Answer DHCP requests when dnsmasq is not bound to the 1st IP of an interface
dnsmasq.20.masuefke at spamgourmet.com
dnsmasq.20.masuefke at spamgourmet.com
Wed Nov 23 23:53:21 GMT 2011
Hello,
>> I ran into an unusual situation:
>> - Network interface is br0, two IPv4 addresses assigned.
>> - First ip port 53 occupied by other dns resolver
>> - Dnsmasq had to be bound to the 2nd ip with options "bind-interfaces"
>> and "listen-address=<2nd ip>"
>> --> Dnsmasq did not respond to dhcp requests anymore.
>>
>> (...)
>> The patch seems a bit crude but works.
> Yes, the current code assumes the the "primary" address of a physical
> interface is the one to be used for DHCP. Note that to start with,
> all you know about a client is what interface it's attached to, so
> selecting which address to use when there's more than one is
> problematic. Your patch kind of ignores this, but what happens if an
> interface has two or more addresses, and you --listen-address on both?
My code searched through the list of interfaces as obtained from
getifaddrs(). The ordering is subject to changes, it may even change
with IP addresses beeing assigned and removed from interfaces. I'll call
it "OS order". Whatever it is. Usually, ethernet hw addresses come first
for all interfaces having one, then the IPv4s and then the IP6 addresses.
The name of the incoming IF is resolved to candidate IP addresses (in OS
order) that are in turn being checked against dnsmasqs listening ip
addresses list.
First match and not matching on any --except-interface will make the
paket "valid".
That works at least around the trouble that DHCP packets on a
--listen-address=<secondary IP address> were not processed at all!
An no processing is like "no DHCP service" :-(
The IP address the server answers with is strictly determined by the
address of the first --listen-address clause of the OS ordering that
matches. Of course, the OS ordered list may be subject to all kinds of
"external" disorder.
If there are multiple IPs that come and go, trouble may arise if the
DHCP client expects to have always the same DHCP server IP address
talking to it (Microsoft requires that, afaik). But nevertheless, if an
interface which had been used for configuring DHCP clients goes down,
there will no more DHCP service on that interface anyways. If the
interface comes back up, and any client sends requests to it via IPv4
unicast, the variable recvd_addr4 will hold the right destination address:
(dhcp.c 220) recvd_addr4 = p.p->ipi_addr;
Outgoing packets will be coming from that very address because
recvd_addr4 is used for setting the outgoing IP address:
(dhcp.c 519) pkt->ipi_spec_dst = srcaddr.addr.addr4;
Thus the client will get e.g. lease renewals from the IP it expects. The
address stored in recv_addr4 is used for checking the available/allowed
interfaces:
(dhcp.c 296) if ((recvd_addr4.s_addr == srcaddr.addr.addr4.s_addr
) || (recvd_addr4.s_addr == INADDR_BROADCAST) )
I think, that makes sense so far. A client can talk to its preferred
server whenever possible, broadcast queries are answered from the first
IP possible.
> This stuff doesn't just affect access control, it affects address
> allocation and things like the default gateway supplied to DHCP clients.
That's a field I have not yet dug into. Why is the server's address
important in this regard ? Does the --dhcp-range depend on the server IP
that answers the request ?
As far as the DHCP optons are concerned, e.g. default gateway, ntp
server, i don't think it is much importatant.
These options can be set with --dhcp-option if needed. Considering the
complexety of a network that uses multiple IPs on a single interface
(some simple firewall configuration scripts/helpers will choke on
this!), an administrator can be expected to configure these options by hand.
As far as the selection of the broadcast address option goes, that is
locked with the used subnet, the --dhcp-range and thus also a fixed thing.
I should have elaborated on my network config some more.
My DHCP servers IPs are like 192.168.0.10/24 and 192.168.0.11/24 , so
the broadcast 192.168.0.255 and the gateway 192.168.0.1 is the same for
all DHCP replies, no matter which IP the requests had been received on.
For running two entirely differnet networks like a 192.168.10.0/24 and
192.168.20.0/24 I'd recomend running two instances of dnsmasq on the
respective DHCP server IP address. Managing the "battle for the clients"
between the servers will be another issue, then (think of using --dhcp-mac)
> -Maybe there should be explicit configuration?
> --dhcp-interface-address = <interface name>, <IP address>
Befeore you spent time on that, I'd rather request an option to have an
interface with DHCP service but no DNS service; but with other
interfaces with both DHCP and DNS (on their default ports!) .
Short: Something like --no-dhcp-interface= but for DNS, maybe
"--no-dns-interface=" ?
That option would have solved all the troubles I went through with the
two interfaces. dnsmasq would only provide dhcp, leaving the other dns
resolver alone on that interface, and being able to query the DHCP
clients host names via DNS on another interface (e.g. lo)
Anyways, big thanks to Simon for all the effort you have invested in
dnsmaq over the years.
-Martin
More information about the Dnsmasq-discuss
mailing list