[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 0.0.0.0 and/or destination
>>>> address 255.255.255.255. 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
>>>
>>> 192.168.1.1 and 192.168.2.1
>>>
>>> Now start two different instances of a DHCP server, one bound to
>>> 192.168.1.1 and the other bound to 192.168.2.1
>>>
>>> A client on the network attached to the interface now starts DHCP by
>>> broadcasting to 255.255.255.255. 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 0.0.0.0 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 0.0.0.0
>> 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.
Simon,
Sorry for the late response. Now I can understand the behaviour of 
dnsmasq.  Many thanks for your clear and detailed explanation.

Mark
>
>>
>> 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