Post by Hugo SegoviaEl Wed, 8 Aug 2018 10:31:01 +0100
Post by Simon Kelleydhcp-match does a substring match, not a regexp or wildcard one: the *
character is not special. Your attempts are therefore looking for a
substring "android*" in the option and failing.
Remove the * and all will be well, I think.
Cheers,
Simon.
Post by Hugo SegoviaEl Mon, 6 Aug 2018 20:39:53 +0100
Post by Simon KelleyUse dhcp-match to set a tag based on the existence of the "android"
substring in the hostname option, and then dhcp-ignore to ignore
all clients with that tag set.
Simples!
Simon.
Post by Hugo SegoviaHello!
First, for "client name" I mean the fourth field in an typical
* this one! *
1532225279 aa:bb:cc:00:11:22 192.168.3.191 android-abcdexyx123456 *
Now, to my issue: I've been asked to setup a little WLAN for free
"Computers 101" courses, and the WLAN does not have any kind of
security (not my choice, BTW...). As you can imagine,
an open WLAN is VERY attractive for freeloaders.
I've been adding "dhcp-host=mac-address,ignore" entries for a
while, but I've been wondering if I could, for example, ignore all
DHCP requests from hosts with a client name like
"android-<somethingsomething>" (because we're not teaching "how to
use your Android smartphone", hence it must come from
freeloaders)
Hello again!
dhcp-match=set:android,option:hostname,android*
dhcp-ignore=tag:android
dhcp-match=set:android,option:hostname,*android*
dhcp-ignore=tag:android
dhcp-match=set:android,12,*android*
dhcp-ignore=tag:android
(since according to
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml
tag 12 = "Hostname")
Whatever I try, it stills keeps giving DHCP leases for Android
devices: dnsmasq-dhcp[1234]: DHCPACK(ethX) <ip addr> <mac>
android-whatever1234
Thank you, that worked out! No asterisk needed, got it!
BTW, I've been trying the "dhcp-vendorclass" option too, and I was
thinking in using it instead of hostnames for the matching-ignore stuff.
"The vendor-class string is _substring_ matched against the
vendor-class supplied by the client, to allow fuzzy matching"
Too bad it didn't occured to me that "dhcp-match" worked in the
same way... Anyway, thanks for the help!
Such "the documentation didn't lead me to expect that actual behavior"
observations are useful. It would be good to make it clearer, though the
sentence "If the value is a string, substring matching is used." is
already in there :)
Part of the problem is that dhcp-match is intended to be very flexible,
and be usable with arbitrary option formats.
That's one reason why something which just matches names, and allows
either exact match or the trailing * might be worth having. The other
reason for that is that there are actually two different options that
can specify the name, option 12 or option 81 (RFC 4702). The data format
of option 81 makes it difficult to use dhcp-match.
There's some security alerts coming down the 'pike that will make the
ability to say "ignore any host which announces name x", or "don't use
the name x if supplied by a host" quite useful.
I'll look at adding such a facility.
Cheers,
Simon.