New entry for Interim packet

[tnt at kalik.net]

>> If you are such a nasty provider that won't allow users to roll over
>> unused allowance into the next period even during the existing session -
>> simply disconnect them at the time the counter resets (use Login-Time on
>> users connecting on the last day for instance). Be nasty to the end!
>>
>
>Its not about being a nasty provider.
>Its about ensuring users pay for what they use and between them pushing out
>bandwidth costs higher than what users pay us each month.
>

It is being nasty, my friend. Lets say you have sold them 5GB for the
month. They used 4GB. And you won't let them use the portion of 1GB
that was left over even if they are on line when counter resets. They
could easily see that as a rip off.

>> If you are prepared to be sensible you should try maths rather then
>> discontinuing sessions. Estimate the usage (if it doesn't *have* to be
>> exact) for the time the session run into the new period and deduct that
>> from the counter limit for each such user.
>>
>
>I don't think disconnecting about 4,000 users is an ideal solution.
>

Well, tough. You can't break sessions without disconnecting users. Maths
it is then.

You can run a perl script on Stop packets that will adjust counter check
attribute value if the counter was reset during the session. This should
work with default counter value in radgroupcheck and individual in
radcheck (group attribute takes presedance but this can be fixed with a
little bit of unlang gymnastics). You will need to wipe those in
radcheck when counter resets next month.

Ivan Kalik
Kalik Informatika ISP