[Dnsmasq-discuss] tagging hosts that don't provide client ID

Simon Kelley simon at thekelleys.org.uk
Sat Feb 20 17:44:47 GMT 2010


Paul Chambers wrote:
> This is a bit off-the-wall, but I thought I'd ask...
> 
> I'd like to allocate hosts to a separate DHCP range if they request a 
> DHCP address, but don't supply a meaningful client ID (either missing, 
> or a MAC address as client ID).
> 
> The reason being that when our network monitoring shows a machine has a 
> problem, if it does not supply a meaningful client ID/name, it's 
> difficult to track down who to ask about it. While our company is still 
> small enough to collect hardware MAC addresses of every physical 
> machine, many machines are also running virtual machines too, so it's 
> not practical to maintain an exhaustive list. And it's often the virtual 
> machines that go unnamed - and later cause problems.
> 
> One way to encourage/remind users to 'name' their machines is to treat 
> the unnamed ones as inferior citizens. I was thinking of putting them in 
> an IP block that has severely throttled internet access.
> 
> The most logical way I can think of is to tag them with a network-id, 
> though I don't see a way of automatically assigning some kind of 
> 'noclientid' tag without patching the source. The only thing I can think 
> of is periodically parsing dnsmasq.leases, and generating a config file 
> containing a dhcp-mac line for every entry that doesn't have a 
> meaningful client id. But that would happen long after the fact, and 
> unless I also prevent such unnamed hosts from renewing the IP address 
> they already were given, they won't be forced to the throttled IP range. 
> Seems fugly.
> 
> Is there a better way?  I'm inclined to create a patch, if no-one has a 
> better idea.
> 
>

dhcp-match=has_clid, option:client-id, *:*:*:*:*:*:*:*

would give you all the machines with client-ids 8 bytes or longer. or
you could match likely mac-address derived ones with something like


dhcp-match=bad_clid, option:client-id, 01:00:*:*:*:*:*

Cheers,

Simon.




More information about the Dnsmasq-discuss mailing list