[Dnsmasq-discuss] double DHCP leases

Simon Kelley simon at thekelleys.org.uk
Sun Aug 31 22:22:47 BST 2008


Nikos Mavrogiannopoulos wrote:
> 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
> 
This comes from RFC2131 and  think makes it fairly clear that the 
behaviour of windows is broken in this case. It also gives the desired 
server behavior

    A DHCP server needs to use some unique identifier to associate a
    client with its lease.  The client MAY choose to explicitly provide
    the identifier through the 'client identifier' option.  If the client
    supplies a 'client identifier', the client MUST use the same 'client
    identifier' in all subsequent messages, and the server MUST use that
    identifier to identify the client.  If the client does not provide a
    'client identifier' option, the server MUST use the contents of the
    'chaddr' field to identify the client.

One reason that I'm reluctant to change the current behaviour is that a 
lot of fiddling occurred early on in the development of dnsmasq to make 
sure that things work in a related but more common situation, when a 
client send a client-identifier sometimes but no client-identifier at 
other times. Related to this, one needs to think about what happens to 
the lease database when more than one client-id is accepted for a lease.

Cheers,

Simon.



More information about the Dnsmasq-discuss mailing list