Matching a prefix in huntgroups file

[Brian Candler]

On 06/11/2016 17:11, Alan DeKok wrote:
> On Nov 6, 2016, at 11:53 AM, Brian Candler <b.candler at 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.