[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