On 06/11/2016 17:11, Alan DeKok wrote:
On Nov 6, 2016, at 11:53 AM, Brian Candler <b.candler@pobox.com> wrote:
Here's something odd then when trying out the "<" operator to check for address within prefix.
(0) policy foo { (0) if (10.254.1.1 < 10.254.0.0/16) { (0) if (10.254.1.1 < 10.254.0.0/16) -> FALSE The parser assumes that most things are strings, unless told otherwise. OK. So that's equivalent to "10.254.1.1" < "10.254.0.0/16" then, which indeed is false.
Try:
if (<ipv4prefix>10.254.1.1/32 < 10.254.0.0/16) { That works, thanks.
So let me try to understand. Is the RHS still initially parsed as a string, but because of the typed value on the LHS, the compare operator automatically casts its RHS from string to ipv4prefix? Another question: I believe there is a separate data type for a single ip(v4) address. The following causes a parse error: /etc/freeradius/policy.d/foo[2]: Parse error in condition /etc/freeradius/policy.d/foo[2]: (<ipv4addr>10.254.1.1 < 10.254.0.0/16) { /etc/freeradius/policy.d/foo[2]: ^ Invalid data type in cast But I get a different error if I try <ipaddr>: /etc/freeradius/policy.d/foo[2]: Parse error in condition /etc/freeradius/policy.d/foo[2]: (<ipaddr>10.254.1.1 < 10.254.0.0/16) { /etc/freeradius/policy.d/foo[2]: ^ Failed to parse field In this case then, I am guessing it's trying to convert the RHS to an ipaddr, which is can't because of the slash. Also, the unlang manpage says that you can't explicitly cast the RHS. If I understand this right, it means that in general, if you have a single IP address on the LHS, you should cast it to <ipv4prefix> to ensure the < operator casts its RHS to an ipv4prefix as well. However, it seems it's not necessary in this specific case; if (&NAS-IP-Address < 10.254.0.0/16) { i.e. in this case it's happy to accept that the RHS could be a (string representation of) a prefix, rather than a single IP address. Thanks, Brian.