I was wondering if it is possible to modify the accounting queries to accept our own Vendor Specific Attributes. I would like to insert the Ascend-Data-Rate attribute we receive from our Ascent (Lucent) MAX TNT machine running TAOS 11. Upon browsing the sql.conf file, my thinking was that if most of the attributes get %{} "escaped" and turned into "variables" that are inserted and modified, that VSAs would too. Upon some testing, at least in my case, I have found that this isn't true. I find that the NAS sends many Vendor-Specific lines that dictionary.ascend contains and FreeRADIUS therefore decodes, but I am stumped as to how to include these in our queries. Is here any documentation or workarounds? Thanks, Wes
Wesley Spadola <wspadola@porchlight.ca> wrote:
I was wondering if it is possible to modify the accounting queries to accept our own Vendor Specific Attributes.
Yes. That's why they're text.
my thinking was that if most of the attributes get %{} "escaped" and turned into "variables" that are inserted and modified, that VSAs would too. Upon some testing, at least in my case, I have found that this isn't true.
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 find that the NAS sends many Vendor-Specific lines that dictionary.ascend contains and FreeRADIUS therefore decodes, but I am stumped as to how to include these in our queries.
Edit the queries to include the names of the VSA's. Read the documentation. Alan DeKok.
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@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
Wesley Spadola <wspadola@porchlight.ca> wrote:
I should have mentioned in my original e-mail before that we're testing FreeRADIUS 1.0.1 on Redhat Fedora Core 3.
You should really upgrade. See http://www.freeradius.org/security.html
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.
Hmm... that shouldn't happen.
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.
radrelay doesn't use SQL statements. And read the debug log to see what the server is getting in a packet, and what it does with that data. Alan DeKok.
participants (2)
-
Alan DeKok -
Wesley Spadola