[Dnsmasq-discuss] double DHCP leases
simon at thekelleys.org.uk
Sun Aug 31 22:25:39 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.
One thing that might save the situation here is that dnsmasq can be
configured to just ignore all client-ids from a MAC address.
If you now which clients have this problem, that might fix it.
More information about the Dnsmasq-discuss