[Dnsmasq-discuss] dhcp-host problem/questrions

Gene Czarcinski gene at czarc.net
Wed Dec 19 22:01:55 GMT 2012


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.

So, want me to run those tests?

Gene



More information about the Dnsmasq-discuss mailing list