|
Tnx Alan, We managed to disconnect
users using “radclient” by sending a fake stop packet We used the following
command :- cat testusertodiscconnect.txt
| radclient -x 127.0.0.1:1813 acct secret_password where secret_password is ths
secret key for localhost (obviously) and the contents of the file testusertodiscconnect.txt
where
User-Name = "testuser"
Acct-Status-Type = Stop
NAS-IP-Address = XXX.XXX.XXX.XXX
NAS-Port = 14745601
Acct-Terminate-Cause = Idle-Timeout
Acct-Session-Id = "45167486" The “Acct-Session-Id”,“NAS-Port”
and “NAS-IP-Address” for testuser where obtained using radwho –i
and radwho –r Note that both “Acct-Session-Id”
and “NAS-Port” where required. Without one of them the user
will not be removed (btw we are using
freeradius-1.0.0 on Fedora core2) Tnx David From: "Alan DeKok"
< To: Subject: Re: RADZAP Date: Wed, 04 Aug 2004
10:57:29 -0400 Reply-To: " > We are running Free
Radius 1Pre3 and wanted to delete a user entry > from radutmp using
radzap. The user entry is not being deleted though! Other people have
said the same thing. > Anyone knows about
issues with radzap? Not really. i.e. Set up a *tiny*
test system. Use "radclient" to send a fake accounting start
packet, to create a radutmp entry. Use radwho to check that the user is
marked as "logged in". Then, use "radzap" to zap
their session. You can also use
"radclient" to send a fake accounting stop packet. That should cause the entry
to be deleted. That will give you
not only simple debugging output, but you will be able to see what *does* cause
the entry to be deleted, and that will give you an indication as to what's
wrong with radzap. In the long run,
radzap should probably be moved to a shell script around "radclient",
and the server should be updated to accept those zap sessions from a
"trusted" client, like "localhost". Alan DeKok. |
- Re: RADZAP David Mifsud
- Re: RADZAP sarky
