OpenWrt Forum Archive

Topic: radius accounting

The content of this topic has been archived on 30 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I'm using WPA w/radius, and already have authorization working, but my question is:
Does OpenWRT do radius accounting these days? Like, tell the radius server when the user logs on and off (the latter is what I'm after, as logon I can already see by authorization).
I saw some posts from 2005 that openwrt does not support it, but am wondering about the current status.

If not supported out of the box, is there a way to still get it working with some modifications?

Last I know it is possible to do accounting.

@belrpr : do you have any documentation about this ?

Like siesop I have searched everywhere and I can't see any info.

On Kamikaze and WhiteRussian there is no information sent to the radius server about accounting.

The only way I have seen is using a captive portal, but when you have WPA "Enterprise" it's not really useful.

Thanks !

if you take a look at the chillispot installation you can see that accounting works.

Yes in chillispot it works, but chillispot is a captive portal...

So the informations about the user (login and IP address) come from the login process in the portal.
I regularly use wifidog and it's the exact same process.

When you use WPA Enterprise, you don't want a captive portal since the users are already authenticated.

So what we need is a mechanism to do accounting based on the informations submitted to the radius server.

I'm thinking about a way to do this : when the authentication is complete on the freeradius server, we use rlm_perl to SSH to the remote AP and look in the ARP table for the IP address corresponding to the MAC who just logged in (we have to way a few seconds until the user receives an address from DHCP or send it's first packet to the router). That way we have the relationship between a MAC address, an IP address and the User.
Then we create an ACCEPT iptables rule for this IP so we have our counter.
Regularly we connect to the AP to fetch the counter value, reset it to zero and add the value in the accounting DB.
Finally we have to cleanup the iptables rules when we are sure the user is no longer logged in (or when the same IP is taken by someone else).

What do you think about that ?

I wish there was a cleaner solution, but I understand it must be quite hard to do accounting with WPA.

klipix wrote:

Yes in chillispot it works, but chillispot is a captive portal...

So the informations about the user (login and IP address) come from the login process in the portal.
I regularly use wifidog and it's the exact same process.

When you use WPA Enterprise, you don't want a captive portal since the users are already authenticated.

So what we need is a mechanism to do accounting based on the informations submitted to the radius server.

I'm thinking about a way to do this : when the authentication is complete on the freeradius server, we use rlm_perl to SSH to the remote AP and look in the ARP table for the IP address corresponding to the MAC who just logged in (we have to way a few seconds until the user receives an address from DHCP or send it's first packet to the router). That way we have the relationship between a MAC address, an IP address and the User.
Then we create an ACCEPT iptables rule for this IP so we have our counter.
Regularly we connect to the AP to fetch the counter value, reset it to zero and add the value in the accounting DB.
Finally we have to cleanup the iptables rules when we are sure the user is no longer logged in (or when the same IP is taken by someone else).

What do you think about that ?

I wish there was a cleaner solution, but I understand it must be quite hard to do accounting with WPA.

The system is the same! Accounting is being done by the the freeradius server.

Here you can find how to configure it. I know it is again with chillispot but here you can see how to activate accounting for freeradius:
http://gentoo-wiki.com/HOWTO_Chillispot … _and_MySQL

Chillispot is using the normal radius accounting to do his accounting.

belrpr wrote:

Chillispot is using the normal radius accounting to do his accounting.

Yes but you have to be authenticated in the captive portal.

In my setup, I don't want to redirect people to a web page, the authentication is already done with WPA.

Chillispot won't do accounting if you are not authenticated in chillispot, because it's the only way to keep track of login, IP, session opened/closed, etc...

klipix wrote:
belrpr wrote:

Chillispot is using the normal radius accounting to do his accounting.

Yes but you have to be authenticated in the captive portal.

In my setup, I don't want to redirect people to a web page, the authentication is already done with WPA.

Chillispot won't do accounting if you are not authenticated in chillispot, because it's the only way to keep track of login, IP, session opened/closed, etc...

I know what you want but your login will do the accounting.  As soon as you authenticated to the freeradius you can do accounting.
DOesn't matter if you use chillispot or wifi dog or something else. Accounting is being done by the radius server!

Anyone have any luck trying to find a solution for this problem ?

I, at least, did not.
Which is a pitty, because accounting would be quite useful in a corporate (or in my case, educational) environment.

I don't think belrpr understood, basically it seems the nas binary does not support accounting.. like.. it does not send something to radius when a user logs off. I want it to work without chillispot/webinterfaces/whatever, just when a user logs on / logs off on the network.
Perhaps with an a non-nas setup it works (hostap), I don't know... Then again, I don't know if it's possible to switch to something else in the first place (using wrt54gl)

Right now we just pull the logged on users every few minutes from the aps by executing 'wl assoclist' remotely.
But that's not a real solution.

(Last edited by siesop on 18 Mar 2009, 15:26)

The discussion might have continued from here.