Cannot disconnect radius user using radclient

[Jon Morby]

On 21 Oct 2013, at 22:08, Alan DeKok <aland at deployingradius.com> wrote:

> 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.

Ok understood .. and believe me I have read what I can find and tried to bend it to my will :)


> 
>> 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.

Yup … basically I need to get the session id AND the NAS id that the user is connected to, all based on the username

We have several LNS and the user could be connected to any of them .. this application has no idea if the user is connected at all, nor where he is connected if he is.  We just need to ensure that at the end of their paid time they are disconnected if they are still connected so the next time they login they get forced into a walled garden (or we just expire their account so they can’t log back in)

What I was hoping for was feed the username into FR, get it to associatively fill in the blanks (the session-id and nas id) and then forward to the LNS concerned

If I send a disconnect with the Acct-Session-Id to the LNS then the user gets kicked off … so I know that works

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

It doesn’t really exist beyond saying 

"RFC5176 Disconnect message and change of authorisation are supported allowing on the fly changes of routing table, closed user group, routes, and line speed without dropping session. Ideal for handling BRAS rate changes seamlessly.”


> 
>  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.

Because all I could see from the help given to the last few people who’ve asked this was “enable outgoing-coa and rtfm” so I did because nothing else was working

> 
>> 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.

Yup that’s what I’m trying to work out how to do … feed it a user-name get FR to add the session id to the equation and proxy/forward it to the relevant NAS as a coa


> 
>> I have coa 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.


Yup and I’m trying to fathom that and missing the rosetta stone … but I am continuing to work the problem and decided (finally) to reach out for help


> 
>> 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?

Because I don’t know which NAS at that stage .. all I know is the username

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

Yup now my question .. how do I tell FR to do “something useful” with the packet (specifically complete the Acct-Session-Id and forward to the NAS which the user is connected to)?

> 
>> 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.

To the CoA / Disconnect request packet .. sorry obviously wasn’t being clear enough in my original post

> 
>> 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 considered that … but I saw how the 2 or 3 other users who have asked this very question were shot down in public and decided to spend more time trying to understand the problem … sadly it didn’t help so I decided to ask for help understanding the fundamentals a little more 


> 
>  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.

I was hoping it would fill in the blanks (based on the coa packet I had “defined” with “update coa”) and then proxy it to the right place

> 
>  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.

Session ID plane and simple

> 
>  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.

They’re in radacct … how do I get them out (can I get them out with FR?)

> 
>  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.

Ok so I need to MySQL query it and not bother asking FR directly for the info?  I was hoping FR would be the API / Interface layer to the DB

> 
>  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.

Yup .. again I was hoping to do this with radius queries rather than bypassing FR to ask the question

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

Other than to submit everything through FR which I was treating as the holy grail / centre of the universe for all our connections

> 
>  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.

Cool … well this is what I was looking for / hoping to trigger …. send a disconnect request into FR, get it to proxy it (based on a policy definition/update in the configs) and avoid having to touch the underlying DB

> 
>  But it still might take 3 years to get standardised.
> 

That fast?  :)  … this isn’t the early 90’s any more sadly :)



>  Alan DeKok.