<div dir="ltr">Thank you, Hugh.<div><br><div>The load is already being shared between multiple instances and request type. It's been a best practice we've been following for a while. </div><div><br></div><div>I will need to have a look at the RADIUS class attribute, but I'm afraid it might not work as expected, since the authentication 3GPP parameters stored in database I want to retrieve come from a different RADIUS client than the one really establishing the session and sending the accounting packets. </div><div><br></div><div>The first authentication flow is sent from the mobile gateway (which sends the 3GPP attributes related to the mobile session I want to keep) to my Radiator.</div><div>Radiator returns the tunnel endpoint for that specific connection (let's call it B)</div><div><div><br></div><div>The second authentication flow is sent from B towards my Radiator server - once authenticated, it starts a session and will send accounting packets as needed - which I need to correlate with information from the first authentication flow. </div><div><br></div></div><div>I'm feeling like I need to clone the AuthSQL.pm code, create a new AuthBy and change the handle_request to react on Accounting packets, fetch the relevant data from database and "enrich" the request packet. I was just curious if there was a direct way to access the database connection handles from within a hook.</div><div><br></div><div>Thanks again.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Bruno Tiago Rodrigues</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 11:55 PM Hugh Irvine <<a href="mailto:hugh@open.com.au">hugh@open.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi again -<br>
<br>
BTW - you should always be running separate Radiator instances for authenticaiton and accounting.<br>
<br>
regards<br>
<br>
Hugh<br>
<br>
<br>
> On 1 Oct 2019, at 07:44, Hugh Irvine <<a href="mailto:hugh@open.com.au" target="_blank">hugh@open.com.au</a>> wrote:<br>
> <br>
> <br>
> Hello Bruno -<br>
> <br>
> Have you considered using the RADIUS Class attribute for this?<br>
> <br>
> You can add whatever information you require for accounting to a Class attribute that is returned when you process the authentication.<br>
> <br>
> The Class attribute will then be included in all accounting requests for the session and you can use the data directly without having to hit the DB again.<br>
> <br>
> Let me know if you need any further information.<br>
> <br>
> regards<br>
> <br>
> Hugh<br>
> <br>
> <br>
>> On 30 Sep 2019, at 23:31, Bruno Tiago Rodrigues <<a href="mailto:bruno.tiago.rodrigues@gmail.com" target="_blank">bruno.tiago.rodrigues@gmail.com</a>> wrote:<br>
>> <br>
>> Our organization has a Radiator server handling a large volume of requests and we're trying to squeeze ops and optimize as much as possible.<br>
>> <br>
>> On one of our recent audits we ran to the production server, we found out that for each accounting request we need to get data from the underlying database from the related authentication packet before processing the accounting itself.<br>
>> <br>
>> There's a PreAuthHook running for each Handler which basically clones the Radiator database connection properties to establish a connection and fetch data from the authentication table.<br>
>> <br>
>> #!/usr/bin/perl<br>
>> <br>
>> sub<br>
>> {<br>
>> use DBI;<br>
>> my $p = ${$_[0]};<br>
>> my $username = $p->get_attr('User-Name');<br>
>> my $anumber = $p->get_attr('Calling-Station-Id');<br>
>> <br>
>> my $dbconn = &main::getVariable('dbconn');<br>
>> my $dbuser = &main::getVariable('dbuser');<br>
>> my $dbpass = &main::getVariable('dbpass');<br>
>> <br>
>> my $dbh = DBI->connect($dbconn, $dbuser, $dbpass);<br>
>> <br>
>> ($country_code, $imei, $rat) = &get_location_info($username, $anumber, $dbh);<br>
>> <br>
>> $p->add_attr('3GPP-SGSN-MCC-MNC', $country_code);<br>
>> $p->add_attr('3GPP-IMEISV', $imei);<br>
>> $p->add_attr('3GPP-RAT-TYPE', $rat);<br>
>> <br>
>> &main::log($main::LOG_INFO,"Got extra RADIUS parameters from database for user: $username");<br>
>> }<br>
>> <br>
>> sub get_location_info {<br>
>> my $query = 'SELECT * FROM (SELECT country_code, imei, rat, row_number() over(order by timestamp desc) rn FROM authentication WHERE username = \''.$_[0].'\' and anumber = \''.$_[1].'\' order by TIMESTAMP desc) tbl WHERE tbl.rn <= 1';<br>
>> my $sth = $_[2]->prepare($query);<br>
>> $sth->execute();<br>
>> my @result=$sth->fetchrow_array();<br>
>> $sth->finish();<br>
>> return @result;<br>
>> }<br>
>> }<br>
>> <br>
>> According to our DBAs, however, this is hurting the database because it requires establishing a connection to the database, logging in and fetching data. Logging in, for auditing purposes, is taking a huge toll on the response times.<br>
>> <br>
>> Is there any efficient way to reuse an existing handle bound to the instance or persistently get a DBI->connect handle on a Startup Hook for each instance and then reuse it inside the PreAuthHook (eventually reconnecting if necessary)?<br>
>> <br>
>> <br>
>> <br>
>> Bruno Tiago Rodrigues<br>
>> _______________________________________________<br>
>> radiator mailing list<br>
>> <a href="mailto:radiator@lists.open.com.au" target="_blank">radiator@lists.open.com.au</a><br>
>> <a href="https://lists.open.com.au/mailman/listinfo/radiator" rel="noreferrer" target="_blank">https://lists.open.com.au/mailman/listinfo/radiator</a><br>
> <br>
> <br>
> --<br>
> <br>
> Hugh Irvine<br>
> <a href="mailto:hugh@open.com.au" target="_blank">hugh@open.com.au</a><br>
> <br>
> Radiator: the most portable, flexible and configurable RADIUS server <br>
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, <br>
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, <br>
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,<br>
> DIAMETER, SIM, etc. <br>
> Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare etc.<br>
> <br>
> _______________________________________________<br>
> radiator mailing list<br>
> <a href="mailto:radiator@lists.open.com.au" target="_blank">radiator@lists.open.com.au</a><br>
> <a href="https://lists.open.com.au/mailman/listinfo/radiator" rel="noreferrer" target="_blank">https://lists.open.com.au/mailman/listinfo/radiator</a><br>
<br>
<br>
--<br>
<br>
Hugh Irvine<br>
<a href="mailto:hugh@open.com.au" target="_blank">hugh@open.com.au</a><br>
<br>
Radiator: the most portable, flexible and configurable RADIUS server <br>
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, <br>
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, <br>
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,<br>
DIAMETER, SIM, etc. <br>
Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare etc.<br>
<br>
</blockquote></div>