[Dnsmasq-discuss] SUCCESS

Simon Kelley simon at thekelleys.org.uk
Sun Oct 21 16:44:36 BST 2012


On 19/10/12 13:52, Gene Czarcinski wrote:
> 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?
>

If I understand you correctly the logging code is there already:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc3315.c;h=9297d52bbd5d13f63810f67b2114704c7b2e9d11;hb=HEAD#l107

Cheers,

Simon.





More information about the Dnsmasq-discuss mailing list