Cannot disconnect radius user using radclient

[Alan DeKok]

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

  That's the issue.  You CAN'T bend it to your will.  You have to
understand how everything works.  And then come up with a solution
within that framework.

  This is a MAJOR reason why people don't get RADIUS.  They think poking
at the RADIUS server will fix things.  It won't.  The NAS is in charge,
not the RADIUS server.

> 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

  That would be nice, but the code doesn't exist.  The SQL module needs
to be update to do this.  It may be difficult, because everyone loves to
mangle the schemas.  And the NAS may not send the data it needs for CoA.

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

  That's a miracle, at least.

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

  And people complain about the FreeRADIUS documentation.  <sigh>

> 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

  No... that is *very* different.  The originate-coa virtual server will
disconnect a user WHEN IT RECEIVES AN ACCOUNTING PACKET.

  So there's no DB query, or anything complicated.  You can just
populate the CoA packet from the accounting packet, which has all of the
fields you need.

  What you want is something very different.  Given a User-Name, look in
the DB to find the Acct-Session-Id.

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

  This information is in the DB.  Look there.

>>  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'll be unhelpful, and say "man unlang".  You have the tools to figure
it out.

  You need to update the CoA packet with data.  The "unlang"
documentation describes how to do this.  You need to grab data from SQL.
 Your SQL server will contain documentation on how to write an SQL query.

  The big problem here is that you don't know which piece is doing what.
 So you can't create a solution out of those pieces.  Instead, you're
poking at it, and expecting it to magically work.

  It won't.  You MUST understand what the system is doing.

> I considered that … but I saw how the 2 or 3 other users who have asked this very question were shot down in public

  Well, I'd wager that they didn't just ask the question.  They asked
vague incoherent questions with no content.  Or, they asked questions,
and then argued about the answers.

  Both behaviors are anti-social, and are discouraged.

  Your question had content.  Intelligent content.  So... you got an
intelligent answer.

> 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

  I was hoping for that, too.  :(

  Unfortunately, the standards aren't written.  So doing the "right"
thing is hard.  And the "automatic discovery" code / configuration is
hard, too.  So it hasn't been done.

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

  You could.  You'd have to write an SQL SELECT statement, with the
associated failure logic.  And the syntax of that statement depends on
your database, and the schema you use to store accounting data.

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

  That's one way of doing it.

>  I was hoping FR would be the API / Interface layer to the DB

  Once you've written the SQL query, you can use it in the FreeRADIUS
configuration:

	if ("%{sql:SELECT ... }") {
		...
	}

  So it all depends on SQL.  FreeRADIUS is just a convenient helper.

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

  FreeRADIUS is a policy engine.  The database stores data.  The two are
very, very, different.

  Alan DeKok.