Hi, we have this problem when OSPF kicks in:
As you will see from the above output when our OSPF kicks in we get duplicate sessions in our Radius.

192.168.199.254 is one high site and 192.168.208.1 is the other high site.

Can anyone help?

You mean the session-timeout is working incorrectly? What I see there is 192.168.199.254 connected for 1 day, then session-timeout. Then another day, then session-timeout. Then another day, then session-timeout...
I see multiple sessions, but I see no duplicate sessions. Is there something I am missing?

ADD: The "caller id" is the same on both ips. So this is the same customer then, correct? It appears is starts another session through the other route when the session-timeout occurs on the first (shortest?) route.

Thank you for your reply.

Yes indeed there is a 'Session-Timeout' in the radgroupreply table of 86400 (24 hours).
This is exactly the same client as you can see from the MAC address.

You are correct my description was not apt I should have said "extra session data". The bottom line is one client cannot be connected on 2010-01-22 for 18 hours AND on on the same day for '1 days'. The reason why this happened is on that day we had a link failure and the OSPF connected another route screwing with the Radius usage data.

It appears is starts another session through the other route when the session-timeout occurs on the first (shortest?) route.

Your observation is correct. That is what I need to fix.

Someone suggested I get another Radius server instead of FreeRADIUS that can 'merge' these kinds of sessions but I would prefer to have this sorted out.

Edit: I changed the topic from "Duplicate Sessions" to "Extra Sessions" to better describe the problem.

I kinda see what you are talking about, but I am not certain how the router on the short route is supposed to close the radius session with the route down. That is why the ospf kicked in and selected the other route, correct?

Yes I guess when the route goes down the Radius session is not closed. But I would like to have it closed because it's leading to lots of accounting issues.

One way to resovle things like this on the FreeRadius side, is to use customized queries for the Accounting Update SQL... The standard queries is very limited in terms of what can / cannot be achieved. Using scripts (rlm_python, rlm_perl) can also easily be used to manipulate accounting data prior to it being sent off to a proxy server, and/or mysql database.

Things coming to mind at the database side is to use UNIQUE contraints on the accounting table, and using for example, 'INSERT INTO ${acct_table1} ... ON DUPLICATE KEY UPDATE ${acct_table1} SET ....', instead of the default UPDATE query supplied by FreeRadius...

FYI: http://dev.mysql.com/doc/refman/5.0/en/ ... icate.html

Customizing check_rad and using user_collision + session limits is also another fine way to circumvent things like this, as FR will validate whether the user is connected as per the 'previous' accounting entry, and if it finds the user is not connected, it will close the previous accounting session prior to opening a new one... With a bit of modification to checkrad, this should also be very, very simple to implement by connecting to the NAS and parsing the wireless registration tables to validate the connection...

Yes I guess when the route goes down the Radius session is not closed. But I would like to have it closed because it's leading to lots of accounting issues.

What solution did you use. I seem to be sitting with the same problem.