Good day

We have setup a couple of Hot Spots and we're experiacing the same challenge on all of them - maybe I took "stupid pills"..?????

Hot Spot works OK and checks in and out with Radius - it presents the User Login Screen to the users and then pops the Uptime Screen and Status as normal....

Here's the challenge:

All the PC's are in a "Class Room - Internet Café" environment....

When the users logout from the system at ANY stage of the Voucher Time and come back to the system - it shows Credit Limt Reached!!!! - no matter what I do I cannot seem to fix this issue...!!!

Any ideas - PLEASE...!!

Thanks

Greetings from Miramar Beach, Florida!

What program are you using to enter data into the radius database? What setting are you using to limit access?

You might need to get into your radius database to find what is happening. The radacct table contains your customers accounting records.

Also, check your clocks.

Tim

Check your radius accounting, as the MT needs to talk back to your Radius server to update their account stating that they are no longer on-line. Otherwise, the time just runs out.

Hi there...

It all seems to be working -
The Radius connects - because if I disable or change anything in the Radius it will not allow the User Login...

The Status Screen pops - with the correct details of the User and time - which (to me) means the Radius is functional.

Now - when the user clicks Logoff on the Status Screen - it "should" cancel the time run-down... which it DOES NOT..!!!!

Voucher Time - Used Time (should) = Time Left -right?? NO - when the user returns his/her time has run down to NIL NADA NIX

All the rest works fine... user login screen, status screen etc.. all looks good - it just WILL NOT kill the user's time once they logoff...

Like I said - maybe I just took "stupid pills" - and it's a simple solution????

Thanks for the time guys...

regards

T

Hi Tanker,

I have a scrip for those "stupid pills" too! I think we all take them now and then.

What setting in radius are you using to limit the time? Just because radius is allowing a login, does not mean all will go well. As in my case, I use the "WISPr-session-terminate-time" setting to limit the time a customer is online. However, if the MT clock is not set correctly, when I check
/ip hotspot active print
it shows 417 weeks left. Much longer than the 3 days they had paid for.

Have you checked your clocks in all your units?

Hey Tim....

Yep - checked the clocks... all seem fine...

System Clock is set with NTP (as with all our units)...

I have tried different DNS - both public and internal (on our side of the network before the tail-circuit) etc... Simply put - when the user clicks on the Logoff Button - it drops the User from the screen - but doesn't switch off the User Timer.

tried the Idle Timeouts
tried culling users (which has nothing to do - but maybe should - have something to do with "keep alive" timeouts)
tried throwing MT

-- but it still doesn't stop the long line of whining users everyday..!!!
We run a seamless network with +250 users (14 BSS) and live a life of relaxed MT bliss.. EXCEPT FOR......aaaaaaarrrrgh!!!!



T

The "user timer"? I am not sure what that is. What are you using to interface with the radius database? Are you using the controller that came with radius? If so, what version of radius are you using? Hopefully FreeRADIUS, so I can be more help.

Have you tried radtest with the radius database to insure it is sending everything you expect to the hotspot? From a shell on the radius server
radtest user password 127.0.0.1 0 radiussecret
Replace user, password, and radiussecret with the appropriate values, and the radtest program should show what is being returned to the hotspot for that user. Insure it is sending the timeout values you expect.

I don't know what you have set for your acct-interim-interval setting, but I use 600. If you don't set that, your accounting time may not be kept up-to-date. Just a thought.

Are you sure that you are getting the Acct-Stop packets correctly at your RADIUS server?
Explicitly check for those Acct-Stop records in your RADIUS database. Otherwise the RADIUS server won't know that the user has logged off and will not stop couting time.

Morning Chris

I'm using the Internal MT Radius - set to 127.0.0.1 with a secret which corresponds with the User-Manager Router...
Once the user is login in with the Voucher details they appear in the User Manager as running...

The User logs off.. and if checked regularly in the user-manager one can see that the voucher time for that particular user continues to count down.. which suggests to me that -- somewhere -- there is not a "disconnect" happening..?????

Sanity is fast disappearing here...!!!!

T

Make sure you are not mixing time-limit and credit-time,
http://wiki.mikrotik.com/wiki/User_Manager/Limiting

I don't think the use of either of those two parameters will affect whether a logoff message is sent to the radius server. I use FreeRADIUS, and it is getting logoff messages from my MT hotspot boxes, along with all the traffic data.

The logoff message is not being received by the radius server, correct? Check your radacct table in the radius database to see what is happening with radius. if it is leaving the acctstoptime set to 0000-00-00 00:00:00. That means "still logged on" (no logoff message). If it is not zero, then you are receiving a logoff message, but not stopping your "timer".

I don't know about the MT version, but I can start FreeRADIUS in debug mode
radiusd -X
and monitor alll activity to and from the server. That should help determine the cause of the logoff failure.

Check your radius accounting port. It is obvious that your authentication port is correct or you could not login. I use 1812 for auth, 1813 for accounting. Check your firewall setup to insure it is not stopping the accounting data too.

SurferTim, he does not use FreeRADIUS.

Tim

I'm not using FreeRADIUS - using the internal MT Radius... somehow there's no "switch this user's voucher time off" getting back to the user-manager - I know this sounds stoopid - but - well - that's the issue at the moment. Once the user logs in on the voucher it'll keep running until all the time goes dead.

I don't see the point of raising a Credit Voucher for 7 days and a User's "uptime" for say - 1 hour... when the Voucher is created under "Credits" in User Manager - that is the Voucher Time sold to the user... The way I understand it is that the Voucher Time is the time a user purchases and the uptime limit is the validity of that voucher... say 1 week. If the user has not used 1 hour withing one week well then tuff - buy another - right??? But during a period of a week the user should be able to login and out for ANY period of time within the voucher time???

T

I'm bleeding here guys...

ANY ideas?????

T

From the link given above,

Credit time
Subscriber can define available credit vouchers. User can buy those vouchers, customers can assign available credits to users. User credits are valid specific time. This means, when a credit is started, it must be used within a time specified. User can have active sessions only while he/she has valid credits. See the example below.

Example
If a user must be allowed to use 2 hours of Internet access and he/she must use these 2 hours within one week, then the uptime-limit field must be set to 2h and the user must be assigned a credit with time equal to 1w (See character constants for more information about time limit constants).

Does your configuration work different ?

GOOD GRIEF..!!!!!! ....

It WORKS!!!!!

I have to say there is a major (look) difference in the upgraded ROS... Got it all running fine now...

Thanks a mill.

T