Session-Timeout Problem

Selahattin Cilek selahattin_cilek at
Thu Feb 2 15:59:15 CET 2017

This is what I have been expecting for quite some time, but I was hoping 
you wouldn't take it to such extremes as dumping thousands of dollars' 
worth of fine equipment. The logic dictates that the NAS learn what it 
is supposed to do from FreeRADIUS and behave accordingly. I have already 
contacted with Ubiquiti Networks PR and I believe their firmware 
development have confirmed this to be a bug in the firmware. They said 
they were going to address the issue.

Thank you all very much.

On 02.02.2017 17:40, Alan DeKok wrote:
> On Feb 2, 2017, at 9:26 AM, Selahattin Cilek <selahattin_cilek at> wrote:
>> I do not want to turn this into a clash of egos, I just want to understand the problem and solve it.
>    That's best done by keeping things technical.
>> This is what I want to achieve:
>> I want to keep user data and statistics in a MySQL database. I want to enforce quota based on the data received by FreeRADIUS 2.2.8 from any NAS.
>    Some NAS vendors support that via VSAs, but it's rare.  Consult your NAS documentation to see what it supports.
>    If they don't support that, perhaps the NAS supports Disconnect-Request attributes.  Again, consult your NAS documentation to see.
>    If both of those aren't supported by the NAS, your only choice is to set a low Session-Timeout.  You can calculate the limit (not 10 minutes...) by calculating their bandwidth limit, and dividing that by the speed of their line.  Then, send that as Session-Timeout.  When they reconnect, do the same calculation.
>> This is my plan:
>> The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers.
>    That's all fine.
>> This is my problem:
>> The NAS receives and recognises the "Session-Timeout" attribute. It authenticates the user and starts counting data. A row is inserted into the "radacct" table. At the end of the first session, the row is updated with the fields:
>> acctsessiontime -> 600 (the same as the Session-Timeout attribute)
>> acctinputoctets -> whatever the user has uploaded
>> acctaoutputoctets -> whatever the user has downloaded
>> acctterminatecause -> Session-Timeout
>> Then the user is authenticated a second time, and therefore a second row is inserted into the radacct table, with an incremented session ID, of course. But strangely, this session never expires and is never updated through Acct-Interim-Updates attribute. The second session lasts forever; that is, until the user turns off WiFi or shuts down his machine.
>    If FreeRADIUS sends the same attributes in the Access-Accept for both sessions, the only conclusion is that your NAS is broken.  Throw it in the garbage and buy one that works.  Ideally, one which supports Disconnect-Request.
>> Why does the NAS terminate the first session as it is supposed to but not the second one?
>    Ask the NAS vendor how their equipment works.
>> Who is supposed to inform who when the session is over?
>    FreeRADIUS, via Session-Timeout.
>> Is the NAS supposed to keep track of this and inform FreeRADIUS, or the other way around?
>    The NAS knows the session timeout only because it's sent in a RADIUS packet.
>> Doesn't the idea of FreeRADIUS keeping track of session time and telling the NAS to terminate the user's session go against the design philosophy of RADIUS?
>    Yes.
>    The problem is you don't really want a session timeout.  You want a bandwidth limit.  And that isn't part of standard RADIUS.
>> Isn't RADIUS only supposed to inform and not enforce?
>    Yes.  The RADIUS server tells the NAS something, and the NAS should behave as instructed.
>>   Who is to blame if the session is not terminated when it should?
>    The NAS.
>> Is there anything I can do with the FreeRADIUS configuration to make that NAS terminate the second session and start the third and so on?
>    No.
>    No amount of poking FreeRADIUS will make the NAS behave properly.
>> Is this a FreeRADIUS configuration issue or is there a bug in the AP firmware?
>    It's a bug in the NAS.  Throw it in the garbage and buy one that works.
>    Alan DeKok.
> -
> List info/subscribe/unsubscribe? See

This email has been checked for viruses by Avast antivirus software.

More information about the Freeradius-Users mailing list