[Dnsmasq-discuss] SUCCESS

[Gene Czarcinski]

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