Cannot disconnect radius user using radclient

[Alan DeKok]

Jon Morby wrote:
> I’m afraid to say I am having very similar problems to the user who has been so sadly flamed for not reading the config/docs/etc/etc/etc ….

  No one gets flamed for not reading the docs.  They get told to read
the docs.  They get flamed when they argue about reading the docs.

> I am trying to disconnect users via a command (eventually a script) when all the available info I have is the username they have logged in with (and whether or not their subscription has expired and they need to be cut off)

  Well... that's the first problem.  Most NAS equipment won't disconnect
a user based just on a User-Name.  They need more.

  What else do they need?  No one knows... read the NAS documentation,
if it exists.

  I've argued in the standards bodies that this is stupid, and there's a
better way.  I was over-ruled.

> I have a coa listener on port 3799 and am issuing the following command with the following results

  Why do you have a CoA listener?  The NAS is the entity which
disconnects a user, not the RADIUS server.  You should be sending the
disconnect packet to the NAS.

> rad_recv: Disconnect-Request packet from host 127.0.0.1 port 57377, id=125, length=42
> 	User-Name = "jonhome1 at fido.net.uk"
> server coa {
> # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa
> +group recv-coa {
> ++[ok] = ok
> +} # group recv-coa = ok
> # Executing section send-coa from file /usr/local/etc/raddb/sites-enabled/coa
> +group send-coa {
> ++[ok] = ok
> +} # group send-coa = ok
> } # server coa
> Sending Disconnect-ACK of id 125 to 127.0.0.1 port 57377
> Finished request 7.
> Going to the next request
> Cleaning up request 7 ID 125 with timestamp +21
> Ready to process requests.

  So... the coa virtual server does what it's configured to do.  Which
is nothing.  If you want it to do something, configure it to do something.

> I have cow and originate-coa in my sites-enabled .. however I have a feeling there should be something other than “ok” in the policy sections, but I can’t find any examples indicating what these might be made to look like

  Because it's impossible to come up with examples that fit your
scenario.  You're supposed to (a) know what you want to happen, (b) know
what the FreeRADIUS modules do, and (c) put the two together.

> my LNS doesn’t seem to report or receive the ack and everything seems to swing around localhost

  Because that's what you told it to do.  You had radclient send a
packet to localhost.  Why not send it to the NAS?

  You had FreeRADIUS configured to do nothing with the packet.  So of
*course* it's not going to send the packet to the NAS.

> I have tried adding the IP address of the NAS (although we have several, but hard coding it for the test hasn’t helped) .. and I’m a little confused ..

  Adding the IP of the NAS to ... what?  That would seem important.

> I have been looking at this on and off for 4-5 months now and am really in need of some help 

  Well, if you can't get it to work in a day, ask questions.  That's
what the list is for.


  I think the fundamental confusion is that you expect FreeRADIUS to do
something magical with the packets.  It can't.  It's just a RADIUS server.

  If you need something *more* than just a User-Name, then read the NAS
documentation to see what it needs.  We can't help there.

  Then, look at the debug output to see if the NAS sends FreeRADIUS
those attributes.  If it doesn't, you're stuck.  If it does, you need to
echo those attributes back in a Disconnect-Request.

  The connection between an Accounting-Request and you sending a
Disconnect-Request is the database.  The session data from accounting
should be stored in a database.

  You can then read the database, keyed by User-Name, to search for the
session attributes.  You don't need FreeRADIUS to do that.  A short Perl
script which reads the database && sends attributes to radclient should
work.

  And send the Disconnect-Request packet to the NAS.  There's really no
reason to send it to FreeRADIUS.

  There *should* be a standard for proxying Disconnect-Messages.  But
RFC 5176 is silent on this topic.  I have a proposal to fix that.  It's
implemented in 2.2.x and 3.0.0, and there are no objections in the
standard bodies.

  But it still might take 3 years to get standardized.

  Alan DeKok.