Withdrawn for shortening.
What is the problem>? I have had not one problem with user-manager, YET. Works great with Kriges automated billing script. No problems? whats wrong on your end>? -Jordan
We’ve a subscriber who runs a back-packers and another who runs a few holiday cottages. I’ve set up hotspot and User-Manager for them and it works really well.
But they along with all our other subscribers pay for an always-on Internet connection with a monthly data cap, subject to a penalty-rate per MB if they exceed the cap.
So they need to be able to access their usage for the current month at any time so’s they know where they are with it, and I need to know at the month’s end if they exceeded their cap and have to pay a penalty.
I haven’t been able to get Kriges automatic billing script to work yet, and don’t know why.
So this month I tried something new and desperate. First thing on Thursday morning, 1st May, I pointed the RADIUS client routers to a brand new, clean User-Manager on a newly installed RB532, and then disabled/enabled the PPPoE client on every CPE on the network - fortunately I only have eight.
My thinking was that would close off all sessions hanging over from April and start everyone off afresh with a session beginning on 1st May so they could use their userman user page to see their usage for the month to date. Moreover the April sessions would be on the old Router for me to check everyone’s usage for the month and raise penalty invoices if required.
But when I checked on the 'new router, which I only powered up on 30th April, I found user sessions going back to 27th April - overlapping sessions for the same time period on the old Router. So in fact there had been double accounting.
All subscribers are limited to one PPPoE session and RADIUS update accounting is set for 10 minutes. I had assumed - lacking any information one way or the other as to how RADIUS works - that a RADIUS client merely sends incremental updates at the set update intervals, with a cumulative tally kept by the server. But it seems the client keeps a cumulative tally and every update click updates the server with the totals for the session.
So by pointing the client at a new RADIUS server BEFORE triggering a new session by disabling/enabling the connection at the CPE, the client closed the extant session going right back to its commencement on the new server and reported it to the new server.
So what I clearly should have done - and will have to do next time at five past midnight on the first of June - was to stop the current session by disabling the connection at the CPEs thereby closing it on the old, April, server, point the RADIUS client at the new server and then enable the PPPoE sessions again so that they started nice and new on the new server, hoping none of my people are on-line at that hour! Easy when you know how it works - if that’s how it does.
Two - maybe three - other things I’ve learned others might like to know.
On the new, May, User-Manager the first session for one client goes back to 18 something hours on the 27th April and then terminates when I instituted the new regime just after midnight on 1st May but on the old ‘April’ User-Manager there are two consecutive sessions for the same user covering the same period and with the same data usage. The break between the two sessions occurs around the time which, from memory, I logged onto the April user and took a note of the month’s usage totals for each user just in case it all turned to custard later. So it would appear that logging on to User-Manager and accessing the sessions page forces User-Manager to artificially close and ‘break’ an on-going session. This is presumably why I was always puzzled to find a number of sessions listed in User-Manager when there should, of course, only be one continuous one which lead me to search high and low for reasons why the sessions were being ‘interrupted’ and even chase up the subscribers to find check the power supplies to their CPEs. And of course the more often I looked in User-Manager seeking inspiration the more ‘interruptions’ there were.
Also User-Manager must, therefore, deduct the record for the first session from all subsequent updates received or there would be double accounting. Given there should have only one session anyway each ‘break’ creates a chain of accounting deductions I’m sure the CPU could do without.
On the April User-Manager the user is, of course, still marked as Active and the last session ‘ends’ some six minutes before it’s logged as ending on the new, May, User-Manager. I would guess this is because this is the time the last update was received from the client. Fortunately the userman web page allows me to wipe the initial overlapping session quite easily and hopefully doing it differently next time will obviate this step.
My last observation is that I had real difficulty working the above out until I realised that the session times on the April server for this user were all -12.00 hours, and that adding back those 12 hours brought the final sessions into line. I have NTP across the network, the NTP server for user’s CPE is the same as all the others and both the RADIUS client and server’s system time was correct. However although on the user’s CPE the NTP client was reporting time synchronised the system clock was exactly 12 hours slow.
Clearly that error was being carried onto the April RADIUS server, but not onto the May one as that records the correct session times. Damned it I can work that one out.
Sorry, couldn’t make it any shorter but I hope my observations as to how User-Manager appears to work helps others struggling with it.
No. Excuse me while I kick the dog, but it doesn’t work.
Removing a session - removing it PERMANENTLY, as you are warned - doesn’t remove it from the user’s tally. Although all the user’s sessions in the May User-Manager now begin neatly in May as I’ve removed the ones going back into April and recorded on the April User-Manager the values for that session - uptime and data used - are STILL logged against the User and appear in his summary if he does a user?= webpage search against his name.
ie although Fred can see a first session beginning on 1st May with only 47MiB downloaded his summary shows him as having over a week’s uptime and having downloaded 1637.7 MiB.
Sorry dog.
Well, The only part i can really help you with is Kriges automated billing script, I was able to get it running Monthend, oversight, usagewarnings, and Billing. If you need any help with it I would be more than willing to help you. -Jordan
If anyone needs information, I’ll gladly enter into this discussion.
I’ve reviewed your posts thus far.
So they need to be able to access their usage for the current month at any time so’s they know where they are with it, and I need to know at the month’s end if they exceeded their cap and have to pay a penalty.
The latter is pretty much already implemented, but I’ve got a ton of free time. I’ll try implement something like that.
I haven't been able to get Kriges automatic billing script to work yet, and don't know why.
I’ve found a few errors that creeps in when you copy my script from the Wiki into Mikrotik. I can help you debug, if you like.
But when I checked on the 'new router, which I only powered up on 30th April, I found user sessions going back to 27th April - overlapping sessions for the same time period on the old Router. So in fact there had been double accounting.
I’ve found a solution for this - I will implement it into my script soon. It involves doing a sortof a “page break” in an active pppoe-session, because that’s what’s causing the problem there.
My thinking was that would close off all sessions hanging over from April and start everyone off afresh with a session beginning on 1st May
bla bla -
No. The accounting session is directly relational to the pppoe-session.
You have to either
A.) Kill the PPPoE link as well, which wil update your radius server with a Session-Terminate thingy. Heh. 
B.) do that little page-break maneuvre, which will essentially set the interim-update data back to Zero and proceed counting - without interrupting the pppoe session.
All subscribers are limited to one PPPoE session and RADIUS update accounting is set for 10 minutes. I had assumed - lacking any information one way or the other as to how RADIUS works - that a RADIUS client merely sends incremental updates at the set update intervals, with a cumulative tally kept by the server. But it seems the client keeps a cumulative tally and every update click updates the server with the totals for the session.
You’re both Right and Wrong. The cumulative tally is kept by the server, correct, as well as by the client. Interim-update facilitates a method to simultaneously have more real-time (or more up-to-date) information available at any given time, and to have a sortof failsafe, should the session end prematurely - i.e. signal loss, power failure, link failure, router failure…
Even if your Interim Updates do not reach your Radius server (whether they are enabled or not) your final Accounting-Close (which is sent to Radius upon termination of the PPPoE session) does contain the “final totals” of the pppoe-session. But suppose for a moment that you do not have Interim Updates enabled, and your Accounting-Close (with the final totals) for some reason Does Not reach Radius - it will mean the accounting session has opened, never updated with usage stats, and closed again on account of failure of some sort - with no stats recorded. Interim update endeavors to circumvent that problem.
Regardless, the problem remains. It doesn’t matter WHEN your pppoe-session ends - But when it does, that is when Accounting-Close is submitted with the cumulative data of the Whole PPPoE Session. Unless you ‘page-break’ it. Reset-Counters does not achieve this, just by the way.
So it would appear that logging on to User-Manager and accessing the sessions page forces User-Manager to artificially close and ‘break’ an on-going session.
That should Not be happening. I consider that a bug. I’ll endeavor to counteract it with my script updates. It may require writing an additional module.
If you would like some help with debugging my billing thingy, you can contact me on MSN. My address is in my user profile on this forum.
-Krige
Thanks jordantrx. Thanks krigevr.
The automated billing scripts did work on my testbench, an i386 running v3.4, but not out in the field on a 532 running 2.9.46 and I’m loath both to upgrade the 532 to v3 yet, or start experimenting on what is one of my main backbone routers.
I’ve just shifted User-manager onto a dedicated 532 with 2.9.51 so that stuffing it up won’t bring the whole network down - that’s the ‘May’ U-M referred to above - and can spend some time on the scripts now but in case my hamfisted efforts turn it all to custard could someone please enlarge on the “Accounting backup” facility in the RADIUS server. What is a ‘realm’ (the manual’s explanation is unhelpful - I suspect “This sceptered Isle” won’t get me far); what do I actually enter here to get a backup record on, say, another RB532 on the network with User-Manager?
I assume this is just an accounting backup, not a full RADIUS failover so that if I do stuff up the ‘May’ 532 I’d need to switch to a backup prepared with all the user details so it can field PPPoE logons. Could this also be the one doing the Accounting backup, or is that a no-no?