[Dnsmasq-discuss] Restrict dhcpd listening interfaces.

Simon Kelley simon at thekelleys.org.uk
Wed Mar 28 13:59:06 BST 2012


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.

>
> Cheers
>
> Ed W
>
> _______________________________________________
> 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