Hello I had this problem too. I found that in the newer versions of freeradius, the read_mainconfig function (in the src/main/mainconfig.c) tests if the port of radiusd is free. If it is not, then exits the program. The problem is that radzap uses the same function.
So, radiusd is running, you try to run radzap, then the function exits because the port is already in use. In older version there was no such test. I solved this issue copying the entire function to a new one, and the new function does not exit the program. Then the radzap calls the new function, say read_mainconfig_zap. Hope it will help you. bye, Luiz Gustavo > Hi, > > we are using freeradius-1.0.0, but to kill user sessions on the radius > server manually, I always used radzap from freeradius-0.7. No other > radzap-version since then - including 1.0.0 - ever worked in my setups. > > But now I have a problem. We added some new querie statements in the > radiusd.conf/sql.conf, which radzap (0.7) can't parse any longer, when > it reads these confs at start-up. > > So I would like to get radzap (1.0.0) to run. Therefore I started the > debug mode with radiusd -X. When I use the old radzap, I see the > generated stop-packet coming in - that is the expected behaviour. > > But when I use radzap from release 1.0.0 (in the same way), there is NO > incoming stop-packet in the debug log. - And the invoked command shows > the following: > > test-radius:# radzap 211.34.61.119 268566633 > Thu Dec 30 16:40:08 2004 : Info: Starting - reading configuration files ... > test-radius:# > > It seems, the radzap command instantly quits while reading some > configuration files. > > What is wrong with the newer radzap versions? > > I'm not a C-programmer - is the only solution for me, to build a > workaround with "radclient", which imitates radzap? > > Regards, > Oliver > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
