[Dnsmasq-discuss] double DHCP leases

Nikos Mavrogiannopoulos nmav at gennetsa.com
Mon Sep 1 07:04:35 BST 2008


O/H Simon Kelley έγραψε:
> 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.

Indeed windows is broken here. My patch was there to allow dnsmasq to
detect those hosts and forbid them from obtaining multiple ip addresses
(consider the case where a host is sending multiple random identifiers-
it is going to flood the server which would result on a DoS).

> 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.
I am not expert in DHCP protocol, I just sent the patch for
consideration, because it improved the behavior (in my setup). However I
dont believe the behavior is changed much. In the case you're describing
the host that uses more than one client-id will be identified using the
first client id that he offered (because the mac address would be the
same). The second client id is effectively ignored (thus enforcing
rfc2131). I haven't got through every scenario that might occur though.


regards,
Nikos




More information about the Dnsmasq-discuss mailing list