Query local active session database (radutmp)

[Christopher Carver]

Quoting TK Lew <tklew99 at gmail.com>:

> hi Chris ::
>
> Thanks for the reply. Yes indeed my situation is a bit dodgy.
>
> I will explore the SQL option as session database.
>
> Thanks again.
>
> BR
>
> On 11/18/05, ccarver at pennswoods.net <ccarver at pennswoods.net> wrote:
> > Quoting TK Lew <tklew99 at gmail.com>:
> >
> > > hi ::
> > >
> > > My situation is complicated. I have freeradius running which accept
> > > accounting start and accounting stop forwarded from customer main
> > > radius (SB).
> > >
> > > Problem is I cannot query the NAS for simultaneous use and the NAS is
> > > using the same NAS Port for each accounting start packet. Since I am
> > > using radutmp for session database , the accounting start and
> > > accounting stop will update the session database.
> > >
> > > But due to some unexplained situation , no accounting stop packet was
> > > received (lost packet or whatever ?) and another accouting start
> > > arrived with the same MSISDN number ( username). In the end I have
> > > duplicate username in the session database.
> > >
> > > So i was thinking of before writing the accounting start packet to the
> > > session database , perhap it is possible to peform a pre-check on the
> > > sesssion database or some preprocess or preacct ?
> > >
> > > Thanks.
> > >
> > > BR
> > >
> > > On 11/17/05, Chris Carver <ccarver at pennswoods.net> wrote:
> > > > On Thu, 2005-11-17 at 23:03 +0800, TK Lew wrote:
> > > > > hi ::
> > > > >
> > > > > Is it possible to query freeradius local session database (radutmp)
> to
> > > > > check for simultaneous use.?
> > > > > If exists delete it using radzap command and then only accept the
> > > > > Accouting Start packet which then eventually written to radutmp.
> > > > >
> > > > > I can write the script to delete but I have not ideas how to
> configure
> > > > > the radiusd.conf for my environment ( if it is can be done ). /
> > > > >
> > > > > Thanks
> > > > >
> > > > > BR
> > > > >
> > > > > -
> > > > > List info/subscribe/unsubscribe? See
> > > http://www.freeradius.org/list/users.html
> > > >
> > > > What are you trying to do?  radwho does the query against radutmp that
> > > > you're referring to.  The -r flag provides all the information radzap
> > > > would need.  I'm not sure what you're trying to do though.  Please me
> > > > more specific about what you're trying to achieve.
> > > >
> > > > -
> > > > List info/subscribe/unsubscribe? See
> > > http://www.freeradius.org/list/users.html
> > > >
> > >
> > > -
> > > List info/subscribe/unsubscribe? See
> > > http://www.freeradius.org/list/users.html
> > >
> >
> > If you have no way to query the NAS for simultaneous use, this puts you in
> a
> > particular situation regardless of what you do with radutmp.  You can:
> >
> > A.  Turn off simultaneous use checking and allow users to connect multiple
> > times.
> >
> > B.  Rely entirely upon the radutmp db to determine if a customer is already
> > connected and accept the fact that due to UDP you will have some stale
> > sessions.  You will need to radzap these as your users file legitimate
> > complaints about not being able to connect.  This is a configuration option
> in
> > the radutmp database.
> >
> > I am still a bit confused about your email and objective.  Keep in mind
> radius
> > accounting happens over udp and you WILL have some lost start/stop packets.
> > This will cause radutmp to be incorrect.  The function of checkrad is to
> query
> > the NAS to find out if radutmp is correct or not.  If you cannot query the
> NAS
> > with checkrad, you have to settle for option A or B listed above.
> >
> > Chris
> > -
> > List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> >
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>


Glad I could help.  But unfortunately keeping radutmp in an sql db probably
won't solve your problem either.  The accounting data will still be coming from
the nas over udp, and therein lies the occasional data loss and source of your
incorrect radutmp entries.