[Dnsmasq-discuss] dhcp-host problem/questrions

Simon Kelley simon at thekelleys.org.uk
Sun Dec 23 21:18:27 GMT 2012


On 23/12/12 20:47, Gene Czarcinski wrote:
> On 12/20/2012 11:12 AM, Gene Czarcinski wrote:
>> On 12/19/2012 05:01 PM, Gene Czarcinski wrote:
>>> On 12/19/2012 11:48 AM, Simon Kelley wrote:
>>>> On 19/12/12 16:21, Gene Czarcinski wrote:
>>>>> On 12/19/2012 08:20 AM, Simon Kelley wrote:
>>>>> Give what you say above about DHCPv6, what needs to be specified by
>>>>> dhclient so that it can get nailed-address if one is available? If it
>>>>> just asks for all of the addresses, how will it know the correct
>>>>> one to
>>>>> use?
>>>>>
>>>> It's the opposite: it shouldn't ask for an address at all, then dnsmasq
>>>> will offer it the nailed-down address. Deleting the client's saved
>>>> state
>>>> should do this.
>>>>
>>> Maybe, maybe not.
>>>
>>> I ran a little test running wireshark on the system with the dnsmasq
>>> dhcp server. One system was the one with the nailed IP addresses. The
>>> second had "regular" dhcp addresses. I did not erase the lease files.
>>>
>>> 1. With the nailed system, there is a series of four DHCPv6 packets:
>>> from nailed to server Confirm with nameand the IPv6 address; from
>>> server to nailed Reply saying Confirm failed; from nailed to server
>>> Solicit with the name; from server to nailed Advertise with FQDN and
>>> IPv6 address.
>>>
>>> A little later, there are two more DHCPv6 packets: from nailed to
>>> server Request asking for a list of info; and from server to nailed
>>> Reply with the answers to the info request.
>>>
>>> 2. With the "regular" client there are only two packets: from client
>>> to server Request with name and IPv6 address (similar to the one
>>> above) followed by from server to client Reply saying "All addresses
>>> still on link"
>>>
>>> I have the trace files and I can send them but I do not want to put
>>> them on the list. They are not that bit but nevertheless.
>>>
>>> What the above says to me is that things were/are working correctly
>>> and when the nailed system asked for the confirm, it was denied. But,
>>> what does dnsmasq do if it gets another IPv6 address even if the host
>>> name is the same?
>>>
>>> I believe I can cause the condition where a different IPv6 was
>>> assigned. In addition, I think I can fake things to recreate the
>>> condition just before I discover what had happened.
>>>
>>> I may be wrong (it would not be the first time) but dnsmasq may not
>>> be clean. No matter what IPv6 address it is given, it should fail the
>>> confirm because of the name match. I suspect that if I used the
>>> DHCPv6.client-id, everything would work.
>>>
>>> Oops. I realized I had to run a third test. Test #2 was with an F18
>>> client so I reran the test with a F17 client. Two packets: Confirm
>>> followed by a Reply saying "All addresses still on link. Something in
>>> F18 changed things to a Request rather than a Confirm.
>>>
>> I have been doing some additional testing and the fact that I ran a
>> version of NetworkManager which did not support dynamic DNS cause new
>> IPv6 addresses. It was also interesting that dhclient will nicely
>> create a new/different client-id every time it is started and the is
>> no lease file ... a new one every time and dnsmasq naturally gives it
>> a new IPv5 address.
>>
>> If you then install the NetworkManager supporting dynamic DNS (which
>> also changes the location of dhclient's lease files) and restart you
>> do get the yet another client ID but you do not get the nailed address.
>>
>> When I rebooted back to F17, I get the nailed address because the F17
>> client-id/IPv6-address was still in dnsmasq's lease file and dhclient
>> was still using the old client-id in the lease file.
>>
>> I believe there might be an "undesirable feature" in dnsmasq which
>> does not always honor/override with the dhcp-host= setting.
>>
>> I have wireshark captures of all the the tests as well as the
>> dnsmasq-leases file if you would like to see them.
>>
>>
> OK, I have been looking at the code in dhcp6.c and rfc3315.c ... this is
> going to take some blood, sweat and tears to work this out. Right now,
> my conclusion is there is no good answer ... just some that are better
> than others.
>
> I thought that there was some specific algorithm is create a client-id
> which would create repeatable/predictable ids ... foolish me. While the
> MAC address is incorporated, there is other stuff that appears random.

You're not the first person to note this.  DHCPv6 and IPv6 in general 
have been out in the R&D wilderness for far too long without being 
widely deployed. They've gathered many rough edges by not getting the 
testing of actual deployment.

>
> I also see that dnsmasq takes into consideration that someone on the
> network may be using a hostname to hijack an IPv6 address ... so using
> the hostname is not a guarantee.

It does, to the extent that if there is a hostname which comes from 
local dnsmasq configuration (--dhcp-host, /etc/hosts, ....) and one 
supplied by the client, dnsmasq trusts the local one.

>
>  From this, I conclude that dnsmasq is not broke and is doing a pretty
> good job.
>
> I believe my solution will need to be two-fold:
>
> 1. Switch to using client-id.
>
> 2. Put in an RFE for new NetworkManager option parameter which would
> specify the client-id to be used. since the client-id can be anything
> (it just needs to be unique), this should work. And then write the patch.

The client-id has some structure, but it shouldn't stop you doing this 
as long as you take that into account. The specs are in RFC3315, I think.
>
> While both hostname and client-id could be hijacked, the hostname is
> something that is "widely" known whereas the client-id is between
> NetworkManager/dhclient and dnsmasq.
>

True.



Cheers,

Simon.

> Gene
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>




More information about the Dnsmasq-discuss mailing list