Hi Alan! Thanks for reply. On Wed, Jan 10, 2007 at 09:32:37AM -0500, Alan DeKok wrote:
Could you check the code in the CVS head? It was updated significantly, to clarify some of these issues. I think it may work a little better.
I have not tried latest CVS code yet, but I have read it. It seems to have same issue. That's why I also included patch for CVS version in my previous email, but I guess it has been overlooked ;). Here is slightly improved version: --- rlm_attr_filter.c 2006-11-22 22:44:19.000000000 +0100 +++ rlm_attr_filter.c.new 2007-01-10 23:52:21.000000000 +0100 @@ -68,7 +68,11 @@ compare = paircmp(check_item, reply_item); if (compare == 1) { ++*(pass); - } else { + } else if (check_item->operator != T_OP_CMP_EQ +#ifdef HAVE_REGEX_H + && check_item->operator != T_OP_REG_EQ +#endif + ) { ++*(fail); } --- 8< --- Code still runs every check_item - reply_item combination through check_pair function, which uses paircmp to do the hard work, but always increments pass or fail counter. After checking filter rules: attribute == value1, attribute == value2 Value of fail will always be >0 and attribute will be dropped. However, I think it would be nice to have way to enumerate list of permitted values (without having to write regex). That's why I suggested possible change of semantics of == and =~ operators in attr filter rules. Single failed comparison will not drop attribute and any matching value will suffice. Are there any other changes in CVS version of rlm_attr_filter I have overlooked which can make it behave as described in attrs file? th.