On Mon, Nov 19, 2012 at 4:25 PM, Angel L. Mateo <amateo@um.es> wrote:
Same configuration, with freeradius 2.2.0 but using radwho from 2.1.8 works. Instead of revert patching the file, I have copied radwho command from previous folders, and it works without any problem.
So it seems that the problem is that now -F options is mandatory instead of optional.
At least you determined that it was a regression. The next step depends on whether a developer cares enough to fix this problem quickly. Of course it would be quicker if you could determine which changeset caused the regresession, or (even better) provide a patch to fix this :)
If this was the only problem, it wouldn't be any problem, but I'm having the same problem with radzap:
/usr/bin/radzap -P 131833856 -u <user> -N <ip> localhost <secret> radwho: No configuration information in radutmp section of radiusd.conf!
This same configuration with previous versions of radius works without any problem.
radzap is now a wrapper around radwho and radclient. If you say previos version's radwho can be used as-is as a simple drop-in, then the workaround should be to just rename or move 2.2.0-version somewhere else and put the working 2.1.x's version in your path. Personally, I don't use either radwho or radzap. I just use sql, plus some modified queries to "automatically" invalidate old sessions (e.g. since we use 1-hour interim-update interval, any accounting records that is not in "stopped" state that is over 2 hour old can be considered invalid). Hope you find the best solution. -- Fajar