[Dnsmasq-discuss] 2.53rc2

richardvoigt at gmail.com richardvoigt at gmail.com
Fri May 28 14:27:11 BST 2010


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.



>
> Cheers,
>
> Simon.
>
>
>



More information about the Dnsmasq-discuss mailing list