[Dnsmasq-discuss] 2.53rc2

[Simon Kelley]

richardvoigt at gmail.com wrote:
> On Fri, May 28, 2010 at 4:18 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
>> richardvoigt at gmail.com wrote:
>>>> Binding 192.168.3.1:67 means that packets from unconfigured hosts which
>>>> are sent to 255.255.255.255:67 have problems on some platforms.
>>>>
>>>> If you set --bind-interfaces then dnsmasq will set the SO_REUSEADDR flag
>>>> on that socket, which allows you to run a relay which also listens on
>>>> *:67, as long as it also sets that flag.
>>>>
>>>> On my list is to add a command-line option to dhcp-helper to do exactly
>>>> that.
>>> IIRC if you use SO_REUSEADDR to bind two sockets to the same address,
>>> it is undefined which of them receives incoming datagrams.  It's
>>> possible that some are delivered to one and some to another, and there
>>> may even be operating systems that deliver to all bound sockets, but
>>> relying on the behavior would be non-portable.
>>>
>> Interesting: do you have any references on that?
> 
> For Unix:
> 
> http://books.google.com/books?id=ptSC4LpwGA0C&pg=PA212
> SO_REUSEADDR allows completely duplicate bindings: a bind of an IP
> address and port, when that same IP address and port are already bound
> to another socket, if the transport protocol supports it. Normally
> this feature is supported only for UDP sockets.
> This feature is used with multicasting to allow the same application
> to be run multiple times on the same host. When a UDP datagram is
> received for one of these multiply bound sockets, the rule is that if
> the datagram is destined for either a broadcast address or a multicast
> address, one copy of the datagram is delivered to each matching
> socket. But if the datagram is destined for a unicast address, the
> datagram is delivered to only one socket. If, in the case of a unicast
> datagram, there are multiple sockets that match the datagram, the
> choice of which socket receives the datagram is
> implementation-dependent. Pages 777�779 of TCPv2 talk more about this
> feature. We will talk more about broadcasting and multicasting in
> Chapters 20 and 21.
> 
> 
> I know Windows is not a platform supported by dnsmasq, but anyway:
> 
> http://msdn.microsoft.com/en-us/library/ms740621.aspx
> In the case where the first call to bind sets either SO_REUSEADDR or
> no socket options at all, the second bind call will "hijack" the port
> and the application will be unable to determine which of the two
> sockets received specific packets sent to the "shared" port.
> If the server application forcibly binds using the SO_REUSEADDR socket
> option to the same port, then the behavior for all sockets bound to
> that port is indeterminate.
> The exception to this non-deterministic behavior is multicast sockets.
> If two sockets are bound to the same interface and port and are
> members of the same multicast group, data will be delivered to both
> sockets, rather than an arbitrarily chosen one.
> 
> 
> 

Many thanks, I shall have to think about how that affects the way things
are done.


Cheers,

Simon.