[Dnsmasq-discuss] dhcp-host problem/questrions

[Gene Czarcinski]

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.

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.

 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.

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.

Gene