some problems with classes

[Simon Hobson]

Andreas Burger <andreas at ethz.ch> wrote:

>  allow mebers of "agrl";
>  deny unknown clients;

That's probably the problem. I can't remember the exact logic, but allow and deny in combination don't work as you might expect. Either use only "allow" in which case anything not specifically allowed is denied, or use only "deny" in which case anything not specifically denied is allowed.

Ah, a quick search came up with this message from the archives :
https://lists.isc.org/pipermail/dhcp-users/2008-January/005273.html

> I _always_ have to check the code.
> 
> 	if ((uid_lease -> pool -> prohibit_list &&
> 	     permitted (packet, uid_lease -> pool -> prohibit_list)) ||
> 	    (uid_lease -> pool -> permit_list &&
> 	     !permitted (packet, uid_lease -> pool -> permit_list))) {
> 
> 		log_info ("not permitted: %s",
> 		...
> 	}
> 
> It's not intuitive...permit and deny lists don't go onto one ACL with
> preservation of order of operations like normal people expect.

I don't know enough about the language (I don't even recognise the syntax of some of it) to reliably determine exactly what it's doing from that.
I *think* it's doing something like :
If there is a deny list, and the client matches any statement in it
  OR there's an allow list, and the client doesn't match any element in it
THEN deny the client
ELSE permit the client (fall through to the following code)

Had to double check in "the book"*, "known" means the client has a host declaration. So actually I think in your case the combination ought to work :
There is a deny list, but because the client is known then it doesn't match
else: There is an allow list, but the client matches it
therefore: the client should be allowed access to the pool.


* The DHCP Handbook by Ralph Droms and Ted Lemon