[Dnsmasq-discuss] SUCCESS

[Gene Czarcinski]

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.

Gene