Accounting VSAs
Wesley Spadola
wspadola at porchlight.ca
Fri Aug 12 17:56:54 CEST 2005
I should have mentioned in my original e-mail before that we're testing
FreeRADIUS 1.0.1 on Redhat Fedora Core 3.
Now, according to the Ascend (Lucent) MAX TNT documentation I have, the
only time Ascend-Data-Rate gets sent out to the RADIUS server is during
an Accounting Stop packet, therefore I only have the % variables in that
SQL statement.
Here is a listing of my stop queries:
sql: accounting_stop_query = "UPDATE radacct SET AcctStopTime = '%S',
AcctSessionTime = '%{Acct-Session-Time}', AcctInputOctets =
'%{Acct-Input-Octets}', AcctOutputOctets = '%{Acct-Output-Octets}',
AcctTerminateCause = '%{Acct-Terminate-Cause}', AcctStopDelay =
'%{Acct-Delay-Time}', ConnectInfo_stop = '%{Connect-Info}',
AscendDataRate = '%{Ascend-Data-Rate}', AscendXmitRate =
'%{Ascend-Xmit-Rate}' WHERE AcctSessionId = '%{Acct-Session-Id}' AND
UserName = '%{SQL-User-Name}' AND NASIPAddress= '%{NAS-IP-Address}'"
sql: accounting_stop_query_alt = "INSERT into radacct (AcctSessionId,
AcctUniqueId, UserName, Realm, NASIPAddress, NASPortId, NASPortType,
AcctStartTime, AcctStopTime, AcctSessionTime, AcctAuthentic,
ConnectInfo_start, ConnectInfo_stop, AcctInputOctets, AcctOutputOctets,
CalledStationId, CallingStationId, AcctTerminateCause, ServiceType,
FramedProtocol, FramedIPAddress, AcctStartDelay, AcctStopDelay,
AscendDataRate, AscendXmitRate) values('%{Acct-Session-Id}',
'%{Acct-Unique-Session-Id}', '%{SQL-User-Name}', '%{Realm}',
'%{NAS-IP-Address}', '%{NAS-Port}', '%{NAS-Port-Type}', DATE_SUB('%S',
INTERVAL (%{Acct-Session-Time:-0} + %{Acct-Delay-Time:-0}) SECOND),
'%S', '%{Acct-Session-Time}', '%{Acct-Authentic}', '',
'%{Connect-Info}', '%{Acct-Input-Octets}', '%{Acct-Output-Octets}',
'%{Called-Station-Id}', '%{Calling-Station-Id}',
'%{Acct-Terminate-Cause}', '%{Service-Type}', '%{Framed-Protocol}',
'%{Framed-IP-Address}', '0', '%{Acct-Delay-Time}',
'%{Ascend-Data-Rate}', '%{Ascend-Xmit-Rate}')"
I have also tried X-Ascend-Data-Rate and X-Ascend-Xmit-Rate with no luck.
radrelay when run locally on the test freeradius server with encoded
production data (Vendor-Specific lines instead of Ascend-* lines) copied
from our Cistron radius does not display "Vendor-Specific" lines /or/
the resultant "Ascend-*" lines that should be replacing the V-S lines
when radrelay is run with -xx. My SQL statements end up with blank
information where the %{} replacements are.
radrelay when run locally on the test freeradius server with decoded
production data (Ascend-* lines) copied our Cistron radius does display
the Ascend-* attributes when radrelay is run with -xx, but does not seem
to change my SQL statements - again, the %{} replacements are blank.
The detail file in both cases are a collection of 5 or 6 days worth of data.
Alan DeKok wrote:
> Wesley Spadola <wspadola at porchlight.ca> wrote:
> No... they don't get "escaped". Read doc/variables.txt. The %{}
> syntax tells the server to replace %{foo} with the VALUE of attribute
> "foo".
I read the documentation you pointed me to and it explained exactly what
I want to know in a concise and straightforward manner - thank you for
that! AFAIK all I have to do to include VSAs into my queries is enclose
the attribute name (eg Ascend-Data-Rate) in the query like so:
%{Ascend-Data-Rate} and it should replace it with the appropriate value.
Is there any more information I could send forth to help debug my issue?
Thanks,
Wes
More information about the Freeradius-Users
mailing list