Freeradius used to get accurate bandwidth statistics

eugenevdm · Sat Jan 07, 2006 2:24 pm

I use a combination of PPPoE, Freeradius, and MT to keep track on customers bandwidth usage.

The problem is that customers cannot see accurate statistics until I end the PPPoE session. It appears that only when the customer's session is ended that the RADACCT table is updated. I would like to know if it's possible, if you're using seperate Radius server, to give customers accurate statistics at any time, in real-time. My workaround at present is to end sessions every 24 hours automatically with the session-timeout attribute, but for better "stability" I would like to never disconnect customer sessions, if possible.

savage · Sat Jan 14, 2006 5:44 pm

Acct-Interm-Update? If you set it to 5 minutes, MT will send a accounting update to Radius every 5 minutes....

What your Radius server does with that update, is up to you. Normally, it will execute a update to my databases holding the accounting data.

eugenevdm · Tue Jan 17, 2006 12:49 pm

I suspected interim was the way to go. I just couldn't work out why it wasn't working with Freeradius. It turns out the management application did not update the required database fields, even though it was receiving updates.

Thanks for your reply though, it put me on the right track.

sublimespot · Sun Jan 22, 2006 5:08 am

I am also using this Freeradius to monitor bandwidth usage. What I am looking for now is a way to de-authenticate a hotspot account after it uses too much bandwidth.

savage · Sun Jan 22, 2006 9:15 pm

Impossible.

Use Session-Timeout, or various other attributes to limit the amount of data that can be received, transmitted, or the duration the user can be on. Radius does not connect/disconnect users, Mikrotik does that, and only when Radius tells the Mikrotik when to do it (during AUTHETNICATION)

tully · Sun Jan 22, 2006 10:13 pm

I think we support radius disconnect -- radius can send packet to the router instructing it to disconnect a client. You will have to check with support and it should be in the manual.

John

tully · Mon Jan 23, 2006 11:47 am

Here is something from a support message:

We don't support PoD, but we have similar feature - DM (Disconnect-Message),
what is specified in the RFC3576.
To enable it use this command "/radius incoming set accept=yes". In that menu
you can also specify on which port to listen.

savage · Tue Jan 24, 2006 9:16 am

FreeRadius doesn't seem to support RFC3576. I haven't come across one (free) Radius server that does currently...

Interesting concept though, after browsing the RFC quickly... Will read up later I suppose.

bluestar · Sat Jan 28, 2006 10:41 pm

Has anybody some example for radius disconnect message sintax or
some for simulations ?

savage · Sun Jan 29, 2006 2:25 pm

Most Radius servers doesn't support it. From what I can gather, the RFC is very brief on how the server is supposed to implement this.

Using a Radius Client however, you can send these attributes to the Radius Server inside MT - which should disconnect the users. Read the RFC, it has everything you need to send inside it.

IMHO, this is still a unreliable method of disconnecting users, as it uses the Radius protocol which is UDP based, and the disconnect message may go 'missing' on a congested network as the UDP packet might not make it to the NAS. Best bet, IMHO, is to use (in the case of FreeRadius), radzap, and the checkrad scripts.

--
Chris.

jager · Sun Jan 29, 2006 3:19 pm

Impossible.

Use Session-Timeout, or various other attributes to limit the amount of data that can be received, transmitted, or the duration the user can be on. Radius does not connect/disconnect users, Mikrotik does that, and only when Radius tells the Mikrotik when to do it (during AUTHETNICATION)

You are right. We are using PPPoE and radius, and live packet is sent every 5 minutes.
Usually, Mtik correctly disconnects the user when it supposed to. But, sometimes this does not happen, and user stays online.
We monitor the users usage every 5 mins, and we made a script that is executed if the user goes beyond his allowed limits.
The script telnets to the router and simply removes his interface.
Simply and primitive, but works

Here is the script:

#!/usr/bin/perl

my $username = $ARGV[0];
my $found=0;

use Data::Dumper;
use Net::Telnet ();

$t = new Net::Telnet (
            Host => "192.168.0.1",
            Timeout => 10,
            Dump_log => "./xyz",
            Prompt => '/\[.+\] > $/');

$t->login("MTIKusername", "MTIKpasswd");

$t->cmd("/interface pppoe-server remove \"<pppoe-$username>\"");
$t->cmd("/quit");

You can also use this telnet trick to do a lot of different useful things automatically

savage · Sun Jan 29, 2006 6:47 pm

Looks good.

The reason why you are not seeing disconnections when they are supposed to happen... Is strange. Session-Timeout / Idle-Timeout / etc are given to te NAS at authentication time, not during accounting sessions. Therefore, if the user authenticated, MT *MUST* have the timeout values. If MT doesn't listen to one, it won't listen to any - the Radius Protocol hardly makes provisions for exceptions

If I where you, I'd have a look at the Auth-Reply detail log of Radius (presuming you are using FreeRadius) for the sessions that does not disconnect. Perhaps it could be possible that for those specific sessions, no Session-Timeout/Idle-Timeout is given as part of the access-accept message.

The script itself... I'd suggest putting it on the WIKI. We need lotsa little hints and tweaks and scripts on there

For reference sakes, you don't seem to use Data::Dumper anywhere in the script, removing the use will speed it up. I'd also in principal, recommend use warnings and use strict.

--
Chris

jager · Tue Jan 31, 2006 2:42 am

savage, thanx very much for your suggestions about the script!
I will ofcourse look after correctly fixing this problem and let Mtik do the disconnection as it supposed to do

Yes, I`m using freeradius. Will look at what Auth-Reply says

but it is a little hard to investigate. We have upto 250 simultaneous PPPoE connections and the good old freeradius gots a lot of requests

EDIT: I`m a little lazy to do any work today.... for God sake, it`s my birthday today

savage · Tue Jan 31, 2006 4:20 am

Happy birthday then

As a final note, I do realise it's not always the easiest thing to take down / reconfigure a radius server - especially with piles of active sessions. Again, presuming you are using MySQL, setup a different Radius server, using the same configs and the same databases.

Then just log the auth-reply details on the new server, for the accounts not doing the timeouts. You can more than likely test this by just running the queries FreeRadius executes against the database with the correct user details. It's either your user-reply (will only affect single user accounts - which is what you are experiencing I guess), or group-reply (which will affect groups of users obviously) that is not sending the correct attributes to FR. Attributes is obviously very sensitive to values, operators, as well as case sensitive, but you knew that, right?

Also worth noting, I'm not 100% now on which way arround right now without digging in some docs, but a reply to a attribute in one table, will overwrite a reply in another table (you need to use priorities if you specify one attribute multiple times). ie. If user-reply give a Session-Timeout := 10, and group-reply gives a Session-Timeout := 86400, the results may not be what you want. MT may also handle duplicate attributes in different ways, or even disregard it completely - I don't know what MT does internally to attributes.

Lastly, there's also raddump (if I'm not mistaken), which is a packet sniffer for the radius protocol. Never needed to use it before myself, but it should give you full details on anything received and transmitted by FR.

I am however pretty sure, the couple of users not disconnecting is merely a issue with a missing and/or incorrect attribute.

--
Chris

jager · Tue Jan 31, 2006 1:43 pm

savage, thanx for all your suggestions, I appreciate them very much! I`m going to play arround with a second radius server (good idea!

) and will post what have I discovered...

sublimespot · Fri Feb 03, 2006 9:07 pm

I enabled Radius with /radius incoming set accept=yes

I tried to perform (Disconnect-Message) via command line:

echo 'User-Name = 00:00:00:00:00:00" | radclient 192.168.10.10:1700 "disconnect" radpasswd

Mikrotik Log says "Radius disconnect with no ip provided'

echo 'ip = 00:00:00:00:00:00" | radclient 192.168.10.10:1700 "disconnect" radpasswd
echo 'user = 00:00:00:00:00:00" | radclient 192.168.10.10:1700 "disconnect" radpasswd

Crashed Radius incoming

savage · Fri Feb 03, 2006 10:06 pm

*please* read RFC3576

2.1. Disconnect Messages (DM)

A Disconnect-Request packet is sent by the RADIUS server in order to
terminate a user session on a NAS and discard all associated session
context. The Disconnect-Request packet is sent to UDP port 3799, and
identifies the NAS as well as the user session to be terminated by
inclusion of the identification attributes described in Section 3.

From the above, IMHO, it is clear, that both User-Name and one of NAS-IP-Address, NAS-Identifier, or NAS-IPv6-Address, is required. These are all given, and described, in full details in Section 3 of the RFC.

ip = and user = is not even propper Radius Attributes

. IP = is actually a MAC address, if you haven't noticed it by any chance. I'm not surprised that it crashed MT's Radius Incoming. Though, MT Staff, I'd prop recommend a NAC be send on any incoming request that is invalid - perhaps simply disgard invalid attributes, such as user = or ip =

Have you perhaps tried:

echo 'Please MT will you disconnect MAC 00:00:00:00:00:00" | radclient 192.168.10.10:1700 "disconnect" radpasswd

Just a thought...

Posts like these *really* peeve me off... sorry.

Freeradius used to get accurate bandwidth statistics

Freeradius used to get accurate bandwidth statistics

Example dor radius disconnect message

Who is online