[Dnsmasq-discuss] negated network-ids (Re: dhcp: mac address as
Lutz at Pressler.DE
Sat Feb 18 11:35:04 GMT 2006
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.
> 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
not work? Only the second line is matching e.g. 00:04:13:01:02:04.
> 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
has the consequence that tel devices don't get those addresses -
but non-tel (no network-id) ones don't either (like # is interpreted
> 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?
Lutz Preßler, Immanuel-Kant-Str. 17, D-37083 Göttingen, +49 551 7700178
More information about the Dnsmasq-discuss