Quoting TK Lew <tklew99@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@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

Quoting TK Lew <tklew99@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@pennswoods.net <ccarver@pennswoods.net> wrote:

...

Quoting TK Lew <tklew99@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@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.