[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