On 10/19/2012 07:11 AM, Gene Czarcinski wrote:
On 10/17/2012 03:18 PM, Simon Kelley wrote:
On 17/10/12 14:54, Gene Czarcinski wrote:
OK, I believe I understand: as you describe it, this is needed for
dhcp4. However, getting a little more understanding of how dhcp6 works
from my last round of debugging, dhcp6 currently does handle multiple
packets. It filters on the IPv6 subnet specified in --dhcp-range and
will only serve dhcp6-packets coming in on the interface which has the
defined dhcp-range subnet. If you specify more than one subnet for a
specific dnsmasq, then it will serve each. Any --interface or
--listen-address is irrelevant. However, the two exclude lists are not
irrelevant and any interface specified in wither of those lists will
block the service.
The problem is that, without SO_BINDTODEVICE, there is no guarantee
that the kernel will route DHCP (v4 or v6) packets to the correct
instance of dnsmasq, when there is more than one.
Now, I assume that all dhcmasq instantiations will each get copies of
all dhcp6 packets. It is their responsibility to process or drop a
packet depending on just what they service.
See above: not a valid assumption.
Mmmm ... now that I reflect on it I may have seen the problem with dhcp6.
A virtual server running kadvd servicing two ipv6 networks and two
instances of dnsmasq each serving dhcp4, dhcp6, and dns on one
network. The dnsmasqs were started with --listen-address but no
--interface.
Four client virtual systems; two on each network.
Services on the server were started first. Then the four clients
enabled their network interfaces. Three of them came up fine with
dhcp4 and dhcp6 addresses. The fourth one had a dhcp4 address but a
SLAAC address for IPv6. Toggle the interface (disconnect;
reconnect). Everything fine the now although it now had a dhcp6 and a
SLAAC address.
The appears to have been the problem. This kind of problem is going
to be difficult to reliably reproduce so one can "prove" that the fix
is the right fix (not that I doubt it). I suppose a some my_syslogs
could be added so there was documentation when packets were dropped.
Simon, now that I have given it some thought, dhcp6_packet() should
never see any dhcpv6 packets except those which it should see. If it
does see a packet which it must drop, that implies things are not
configured properly.
For example, if I specify a network in --dhcp-range which happens to be
on eth0 and then put eth0 in one of the exclude lists, something is wrong.
If --interface and/or --bind-interfaces were not specified and the
device name associated dhcpv6 packet does not match the device name
associated with a --dhcp-range that was specified, this is an error.
It might be appropriate to add my_syslog() warnings when such things occur.
Comments?
Gene
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
