Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a freeradius setup that is being used to provide authentication for users on a wireless network.

The access points are all Mikrotik hardware and the users are connected 24/7.

We've been using Daloradius with mysql and freeradius 2. The boss wants to use the accounting information and while this is all set up and appears to be working, I've found that not all the accounting information is present.

Since our users may be connected for more than 24 hours at a time we keep this in here, it will reset some attributes daily so that the accounting packets work correctly.

So he started poking around at this link: http://wiki.mikrotik.com/wiki/RouterOs_MySql_Freeradius#Configuring_RouterOs_for_Radius_.26_PPP.2A_AAA

And was looking specifically at the following section.

Since our users may be connected for more than 24 hours at a time we keep this in here, it > will reset some attributes daily so that the accounting packets work correctly

   always fail {
           rcode = fail
   }
   always reject {
           rcode = reject
   }
   always ok {
           rcode = ok
           simulcount = 0
           mpp = no
   }

However, that link references freeradius 1 and I can't find this in the radius.conf file for freeradius 2. What does it do and could it be a reason I'm missing data?

EDIT: I have found one issue. We have a backup freeradius server that is also receiving the accounting packets. Although they are replicating, it's only a master/slave configuration. If the slave receives accounting packets it won't replicate them back to the master.

Although I suspect this might solve it, the boss is not convinced due to the always module. Is there anything special I need to configure in the mikrotik AP's or freeradius 2 for clients connected 24/7.

share|improve this question

1 Answer 1

I looked at the URL you provided and I found that an interesting way of doing it. I would seriously consider the fact that the example is possibly outdated before relying on it.

On our FreeRadius implementation we get around the accounting updates problem by setting a timeout in our Radius database. We do this by having a Attribute "Session-Timeout" op "=" and Value "86400" in the radgroupreply table.

This has the effect of "timing out" the user every 24 hours. Most PPPoE clients (including ADSL and MikroTik routers) are programmed to reconnect strait away. This is normally a split second operation on a MikroTik client router and in theory not that disruptive. My tests have however shown that it can in fact break certain TCP/IP operations, e.g. downloads.

However, the method we use seems very reliable and a good failover method if your interim updates fail or your disconnect method breaks.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.