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@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
