[Dnsmasq-discuss] negated network-ids (Re: dhcp: mac address as "range selector"?)

Simon Kelley simon at thekelleys.org.uk
Sat Feb 18 14:32:48 GMT 2006


Lutz Pressler wrote:
> Hello Simon,
> Am Samstag, 18. Februar 2006, Simon Kelley schrieb:
> 
>>Lutz Pressler wrote:
> 
> 
>>> dhcp-vendorclass=tel,alcatel.noe.0
>>> dhcp-range=net:tel,192.168.71.2,192.168.71.5,255.255.255.248,12h
>>> dhcp-range=192.168.169.80,192.168.169.99,255.255.255.0,12h
>>> dhcp-boot=net:tel,,,192.168.70.3
>>>
> 
> 
>>>I try to differenciate by ethernet address (00:04:13:*:*:*)
>>>as a work around.
> 
> 
>>> dhcp-host=00:04:13:*:*:*,net:snom
>>>
>>>does not have the effect of using range and option definitions where
>>>network-id snom matches - which I think would be a logical extension.
>>
>>I think it should work, but there's a limitation that only the first 
>>matching "dhcp-host" line is used, so you couldn't have
> 
> Yes, it does work - as the brackets in the man page section for
> dhcp-host imply - that's why I tested it before. The problem was:
> I tested it after the device already got an address from the other
> range and I had not deleted the dhcp.leases file/entry. The old
> address was acknoledged.
> Is this intended behaviour? If the old IP address is not defined in the
> new configuration at all, it is not acknowledged. I don't think these
> more complicated cases have to be detected - it may suffice to document
> the necessity to manually clean up.

The dhcp-range=net:<tag>,...... affects which range is used to offer an
IP address to a host, but it doesn't move hosts with existing IP
addresses. That used to be the case for dhcp-host lines too, if a host
already had an address, then  nailing it to  different address wouldn't
move it. Eventually, I was persuaded that it's OK for dnsmasq to refuse
to renew the old lease for a single host, and instead tell it "move to
this IP". I didn't do that same for whole sets of machines, the chaos of
having lots of machines moving IP addresses at unpredictable times as
their leases expired it too bad.

As an alternative to editing the leases file, you can tell the DHCP
client to release the address.

> 
> 
>>dhcp-host=00:04:13:*:*:*,net:snom 
>>_and_
>>another dhcp-host line (or /etc/ethers entry) to assign specific IP 
>>address to a specific MAC address.
> 
> What does "first matching" mean? I haven't tested, but why should
>   dhcp-host=00:04:13:01:02:03,192.168.10.11
>   dhcp-host=00:04:13:*:*:*,net:snow
> not work? Only the second line is matching e.g. 00:04:13:01:02:04.
> 

It's not defined. dnsmasq looks through the dhcp-host lines until if
find one which it can use, and then it stops. The order is arbitrary
because it's not normally sensible to have more than one dhcp-host line
usable at a time.

This assumption is questionable when there are wildcards, hence my
warning and your question. The answer is "don't do that", you can assign
 to a network using MAC-address wildcards, or you can assign an IP
address to a host, but you can't mix them.

> 
>>If it doesn't work, that's a bug.
> 
> No bug here, but maybe...
> 
> 
>>>As a side note a related "issue": The definitions above do give "tel"
>>>devices an address from the normal range if the "tel" range is exhausted.
>>>I see no way to change that as it's not possible to negate network-id
>>>usage or mapping.
>>>
>>
>>Yes it is, though the documentation is well hidden in the man page, I 
>>will admit
> 
> I read that, tested - and then interpreted "#" as being only relevant
> in dhcp-option (btw, there is a typo --dhcp=option=#purple...).
> I have not tried dhcp-boot and dhcp-ignore, but
> 
>>dhcp-range=net:#tel,192.168.169.80,192.168.169.99,255.255.255.0,12h
> 
> has the consequence that tel devices don't get those addresses -
> but non-tel (no network-id) ones don't either (like # is interpreted
> literally). 
> 
>>Again, I've not tested that recently, so it is possible that it has 
>>suffered bit-rot: I guess few people use it.
> 
> Do you look into the sources or should I?

I just got your subsequent message, so I'll send this reply and answer
that in  another reply.

Cheers

Simon.

> 
> Lutz
> 
> 




More information about the Dnsmasq-discuss mailing list