[Dnsmasq-discuss] Restrict dhcpd listening interfaces.

Mark Wu wudxw at linux.vnet.ibm.com
Thu Apr 5 10:59:09 BST 2012

On 03/28/2012 08:59 PM, Simon Kelley wrote:
> On 28/03/12 12:23, Ed W wrote:
>> On 27/03/2012 21:49, Simon Kelley wrote:
>>> On 27/03/12 15:18, Simon wrote:
>>>> The strange packets have source address and/or destination
>>>> address When an socket is bound to a particular
>>>> address, it may not receive these packets. Some kernels work fine,
>>>> but it's really moving into undefined territory and portable code
>>>> which works everywhere is much easier when binding the wildcard.
>>> As an example of the sort of trouble you can get into with this, 
>>> imagine
>>> a physical network interface with two IP addresses, say
>>> and
>>> Now start two different instances of a DHCP server, one bound to
>>> and the other bound to
>>> A client on the network attached to the interface now starts DHCP by
>>> broadcasting to Which DHCP server instance should 
>>> reply?
>> Surely that specific problem is just badly phrased - the situation is no
>> different whether you have two instances on one machine or two instances
>> on two machines? The problem there is that you have two instances
>> listening to a broadcast address? (ie it would make no odds if you have
>> two instances bound to or bound to something else - the issue is
>> the two instances?)
> It's different in that it's less likely to work and the behaviour is 
> more undefined. If you bind the address of a local interface to a 
> socket and set SO_BROADCAST, you expect to get broadcast packets. Plug 
> two such machines into a physical network and both will receive the 
> broadcasts. Put both sockets in the same machine, and it's not 
> necessarily defined what happens.
>> Wasn't the original question the difference between binding to
>> vs binding to each interface individually?
> The fundamental problem here is that you can only (portably) bind a 
> socket to an IP address, not to a physical interface. The mapping from 
> (packet arrival interface, packet destination address, address(es) of 
> interfaces) to bound socket address isn't well defined in all cases, 
> for instance the one I gave above.
> Linux has a sockopt, SO_BINDTODEVICE which does this job admirably, 
> but isn't portable. There were very early versions of dnsmasq which 
> used it. When I ported to *BSD I moved to the current scheme because 
> it works everywhere and makes the fewest demands on undefined behaviour.
> Cheers,
> Simon.
Sorry for the late response. Now I can understand the behaviour of 
dnsmasq.  Many thanks for your clear and detailed explanation.

>> Cheers
>> Ed W
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

More information about the Dnsmasq-discuss mailing list