[Dnsmasq-discuss] double DHCP leases

Nikos Mavrogiannopoulos nmav at gennetsa.com
Fri Aug 29 21:19:01 BST 2008


O/H Simon Kelley έγραψε:
> Nikos Mavrogiannopoulos wrote:
>> I've come across to a situation where dnsmasq was giving two IP
>> addresses to certain (windows) hosts. The problem was that the windows
>> host was requesting two times for an IP but having a different client
>> identifier (check the wireshark output). 
> Looks like windows is using RFC2132-like behaviour (client-id derived
> from MAC address) then moving to RFC4361-like behaviour (DUID
> client-id). Is this a big problem? the first lease will expire and
> release the IP address in time.
Unfortunately in my case it was annoying because the user had to select
his host from a menu. His host was displayed using DHCP data, that were
duplicate in this case.

>
> I've fixed this using the
>> attached patch. In that patch I make lease_find_by_client() to return
>> the lease of any of the MAC and the ClientID match. The previous
>> behaviour was that if client IDs are there, it didn't check the MAC
>> address. What was the reason for that?
>>
>
> Yes, it's what the RFCs mandate. If a client-id is provided, it shall
> be used as the host unique-identifier, and the MAC address ignored.
> See RFC4361 section 6.3 for the definative statement on this.
Actually my understanding of this RFC is that client identifiers must be
used as identifiers for a host. Ie one client identifier might identify
several MAC addresses that belong to a single host. I don't think it
forbids disallowing multiple client identifiers per MAC address (what my
patch does). Their goal was to allow a single entity (pc) to be able to
identify itself by using a unique identifier over several different
interfaces (with different mac addresses). What the current
implementation allows is to have a single entity (pc) to identify itself
several times using different names (identifiers) over a single MAC
address. That case is not in scope of RFC4361, thus my patch might not
be that bad.

regards,
Nikos



More information about the Dnsmasq-discuss mailing list