I have found a potential bug in the way rlm_file or valuepair does the xlat of %{var} items. These are supposedly dynamic, being based on a per-packet replacement. The following example can be done a different way but its the simplest example I can think of ;-) Take the following from a users file (X-MyCLI filled in from some db in an earlier module). DEFAULT X-MyCLI != "%{Calling-Station-Id}", Auth-Type:="Reject" The db of valid CLI's might contain. user cli --------------- one 12345 two 54321 If you do two queries that should auth one thats sending: username=one, callingid=12345; the other username=two, callingid=54321. Only the first works the second failing because the in memory config for the check will have changed to read X-MyCLI != 12345 ...!!! Looking at the code this appears to be due to paircmp expanding the %{} on the structure passed to it (a potentially bad idea for so many reasons). The best solution, I suspect, is to copy the data sent to paircmp and work on the copy and not the original. The copy can be done on a per-pair way and if deemed expensive only for things that need xlat. .............................................. In sudo code: for (check; check->next ; ..... memcpy(&blah, check, sizeof(check)); Do the comparison using blah instead of check. memcpy(check, &blah, sizeof(check)); ............................................... I don't have a detailed patch yet as I have only done half the work required to avoid trashing the config but thus far it does fix my case. PS: Although I have only looked at 1.0.2 this appears to hold true of the CVS head as well. Am I missing something here and if not I'll be back soon with a complete patch (Currently I just save the old check_item and put it back which is fine in a single thread but not so clever in a threaded system). -- Alister Winfield