RADIUS: Max-Session-Time attribute not defined

RouterOS General
1

Hello All,

We’re in the process of setting up a hotspot. We would like to sell users a limited amount of time, after which they would need to come and buy more before they can log on again.

I believe the RADIUS attribute I need to pass to the AP is Max-Session-Time. However, the manual says

Max-Session-Time > - maximum session length (uptime) the user is allowed to

So I’m only guessing it’s meant to finish along the lines of ‘log in for’.

Unfortunatley, the Max-Session-Time attribute doesn’t appear to be declared in any of the RADIUS dictionaries I have looked at (the ones that come with FreeRADIUS, and the ones pointed to from http://www.mikrotik.com/docs/ros/2.9/guide/aaa_radius).

Would anybody be able to tell me:

  • Whether this is indeed the attribute I’m after
  • Whether it is supported on the RB532
  • What its attibute number and type (integer?) are so I can add them to my dictionaries.

I found a similar post from Nov 2005 at http://forum.mikrotik.com/t/max-session-time/3858/1 That poster was able to use the Session-Timeout attribute - unfortunatley, this doesn’t meet my needs (as the user can log straight back in again with the same username/password pair).

Thanks in advance.

Edit: RB532 running ROS2.9.27 on Firmware 1.13

2

Max-Session-Time is not what you are after if used alone. This attribute tells RouterOS how long one “login” may last, i.e. if the user is allowed to have at most 1 (continuous) hour being online. This does however not stop him from logging in again immediately.

What you are after has to be done through scripts on your RADIUS server. You will want to have a database where the “total left online time” for each user is configured. Then send THIS value as Max-Session-Time to your Hotspot on login. So the user may not be online longer than he has credit left.
On every logout of a user you have to have a script on your RADIUS server subtract the time the user actually was online (RADIUS: Acct-Session-Time) from his left-over credit. When your user is logging back in now, he will get a Max-Session-Time that reflects his past usage.

I hope that was clear enough - it’s just too hot here to think about too complex things right now :wink: …

Best regards,
Christian Meis

3

Classic case of the sqlcounter module (experimental.conf - not that it is a experimental module anymore).

  sqlcounter noresetcounter {
    counter-name = Max-All-Session-Time
    check-name = Max-All-Session
    sqlmod-inst = sql
    key = User-Name
    reset = never
    query = "SELECT SUM(AcctSessionTime) FROM RadiusAccounting WHERE UserName=TRIM(LOWER('%{%k}'))"
  }

  sqlcounter dailycounter {
    counter-name = Daily-Session-Time
    check-name = Max-Daily-Session
    sqlmod-inst = sql
    key = User-Name
    reset = daily
    query = "SELECT SUM(AcctSessionTime - GREATEST((%b - UNIX_TIMESTAMP(AcctStartTime)), 0)) FROM RadiusAccounting WHERE UserName=TRIM(LOWER('%{%k}')) AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%b'"
  }

  sqlcounter monthlycounter {
    counter-name = Monthly-Session-Time
    check-name = Max-Monthly-Session
    sqlmod-inst = sql
    key = User-Name
    reset = monthly
    query = "SELECT SUM(AcctSessionTime - GREATEST((%b - UNIX_TIMESTAMP(AcctStartTime)), 0)) FROM RadiusAccounting WHERE UserName=TRIM(LOWER('%{%k}')) AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%b'"
  }

just a brief example… The above obviously just defines it, I’ll leave it up to you to configure it, setup the attributes, and the relavant sections in the radius config file.

4

Danke Christian - Your explanation regarding scripting was perfectly clear.
savage - Thanks for the example script, much appreciated.

Then send THIS value as Max-Session-Time

Well, I would, but Max-Session-Time doesn’t appear to be in the dictionaries… :laughing:

Also, I am now a little confused as to the difference between Max-Session-Time and Session-Timeout - from http://www.mikrotik.com/docs/ros/2.9/guide/aaa_radius:

Session-Timeout - overrides session-timeout in the default configuration

and from http://www.mikrotik.com/docs/ros/2.9/guide/aaa_hotspot

session-timeout > (time; default: 0s) - session timeout (maximal allowed session time) for client. After this time, the user will be logged out unconditionally

So, it appears Session-Timeout behaves the same way as Max-Session-Time does? Why have 2 RADIUS attributes that do the same thing - I must be missing something here.

It seems a little strange that there is no RADIUS attribute that maps to the ‘Limit Uptime’ option for Hotspot Users - after all, the two other options on that tab (‘Limit Bytes In’ and ‘Limit Bytes Out’) are mapped to RADIUS attributes (Recv-Limit and Xmit-Limit), and ‘Limit Uptime’ would seem to me fairly essential functionality for a hotspot.

I’ll look into scripting as suggested, but for now I get the feeling I’ll probably just create users on the MT with ‘Limit Uptime’ set - we are only a small WISP and it’s not going to kill me to do it manually to begin with (and will mean a slightly quicker roll-out).

If either of you (or anyone else!!) has any further thoughts or insights, I’d be very grateful if you would post them here.

In the meantime, thanks again for your replies.

5

Max-Session-Time = a CHECK item, NOT a reply item. Therefore, the Radius server receives this attribute from somewhere, does a check on it, and allow or deny authentication based on it.

In this case, Max-Session-Time is provided from the Radius Server itself, based on the configurations I have provided.

Session-Timeout := 5 (REPLY Item), The user connects, the NAS allows the user to stay connected for 5 seconds, and then disconnects the user. Once the user re-connects, he will again be disconnected in 5 seconds, etc etc etc.

Max-All-Session := 500 (CHECK Item), The user connects, Radius checks via it’s accounting database just how long the user has been online. If the user has been online for more than 500 seconds, the Radius Server will DENY authentication to the user. Because this is a CHECK item, it has NOTHING to do with the NAS

Max-Daily-Session := 500 (CHECK Item), THe user connects, Radius checks via it’s accounting database just how long the user has been online. If the user has been online for more that 500 seconds on the CURRENT DAY, Authentication is denied. Again, this is a CHECK item, it has NOTHING to do with the NAS

Max-Monthly-Session := 500 (CHECK Item), same as Daily-Session except it’s calculated over a period of the current month instead of the day. Again, a CHECK item, again, it has NOTHING to do with the NAS.

In a nutshell thus, Session-Timeout is a REPLY item (It gets sent to the NAS), and the NAS does the work to disconnect the user once the timeout period expired.

Max-All-Session (which you can easily rename to Max-Session-Time by editing the configuration), Max-Daily-Session, Max-Monthly-Session, Max-AnythingYouWantToSetupInRLMSQLCounter-Session, is a CHECK item. It is handled internally on the Radius server, and NEVER sent to the NAS. The Radius server does the calculations on whether or not to allow/deny authentication for the user once a amount of time online has expired…

I don’t think I can be more clear than this… It’s not rocket science?

6

savage,

Perhaps there has been a misunderstanding here?

When I refered above to the Max-Session-Time attribute, I was not refering to anything from your script. rather the attribute detailed at http://www.mikrotik.com/docs/ros/2.9/guide/aaa_radius, in the section ‘Supported RADIUS Attributes’.

Under the ‘Access-Accept’ subheading, there is a (partial) entry for ‘Max-Session-Time’. As this is listed as a supported attribute for access-accept messages (which I understand only ever go from the RADIUS to the NAS - ie a REPLY attribute), I would of expected to be able to send this attribute to the AP. In which case, I was curious how it differed from the Session-Timeout attribute, detailed directly above it on the aforementioned page, as well as why its listed there and not in the dictionaries.

7

Ok, so let’s play with that idea :smiley:

User ABC connects. He authenticates via radius, radius sends a Session-Timeout := 600. In this case, the NAS knows that in 600 seconds, it needs to terminate the connection for user ABC. That’s all fine and dandy.

Now, let’s send Max-Session-Time. User ABC connects. He authenticates via radius, radius sends a Max-Session-Time := 600. The NAS will NEVER know when to disconnect this user, seeing that the NAS has NO knowledge of how much time was spend online already :slight_smile: The calculation HAS to be performed by the radius server - as the radius server is the only item in the chain of authentication that has records to accounting data…

Buy anyways… This is what you are after… Implement it, play with it, and come back and thank us when it’s done. The radius server gets the max allowed time from a check attribute (which you add in the users file as part of the user authentication block - similar to a password), the radius server then checks how much time was spend online already. Max-Session-Time thus equals total allowed time - time already used. The difference, is then sent to the nas as a session-timeout so that the NAS terminates the connection once the max allowed time is used.

It works flawlessly, done it hundreds of times…

8

seeing that the NAS has NO knowledge of how much time was spend online already

Yeah…fair point… :blush: (still midly curious what the max-session-time attribute is meant to be though…)

Just finished some initial testing with those scripts and they work like a charm (I never doubted they would for a minute!)

Thanks both for you help.