Hello Mariano -
I think you are getting much too complicated.
My suggestion is to create a Handler to catch the "Alive" packets
from the NAS and either use an AuthBy SQL clause with
AcctSQLStatements to do what you require in the the session database,
or to write a hook that does the same thing.
BTW - I don't think there is any way to send instructions to the NAS
from Radiator to turn on the Alives. This will have to be configured
directly in the NAS.
regards
Hugh
At 16:59 -0300 01/2/20, Mariano Absatz wrote:
>Hi Hugh, Mike,
>
>I didn't find anything specially fitting in goodies/hooks.txt, but I
>kinda saw a way to do it.
>
>I also browsed through the source and found that SessGeneric.pm has an
>"update" function for "alive" (a.k.a. Interim-Update) packets.
>
>Is there a "clean" way to generate an "UpdateQuery" and mayba also an
>"ExceededQuery"?... in particular, I don't see this handled in SessSQL.pm
>
>I would also need to change the "exceeded" function in SessSQL.pm. On the
>other hand, I can (maybe this is "cleaner") add a new "InterimUpdate"
>NasType and create an isOnlineInterimUpdate function in Nas.pm.
>
>Is there a way to have an attribute "attached" to a <Client> clause? That
>is, I need a way to specify the Interim-Update, first to send it to the
>NAS so it starts sending Alive packets at the interval I want and then
>for checking that the timestamp in the SessionDatabase is not to old. As
>for what I read, I can set a global variable and use it everywhere, but
>it would be cleaner if I can bind it to the client (where I think it
>belongs, at least as much as the NasType).
>
>The idea is that the UpdateQuery updates the Timestamp column and that
>the ExceededQuery tests the current timestamp against the SessionDatabase
>timestamp... say,
>if (current_timestamp - sessDB_timestamp > Interim-Update * 1.1) {
> "I declare this entry of the SessionDatabase is stale and erase it";
>}
>
>If I add the "InterimUpdate" NasType, I would have to check for this
>difference in isOnlineInterimUpdate (in Nas.pm), so I would need to have
>this Interim-Update attached somewhere... there is allways the quick an
>dirty GlobaVariable, but if there is a clean way, it might find it's way
>into Radiator 2.19 or 2.20 maybe ;-) (I hate to diff original/modified
>files and triple-checking before upgrading) :-(
>
>Am I completely off-base?
>
>El 15 Feb 2001, a las 12:59, Hugh Irvine escribió:
>
>>
>> Hello Mariano -
>>
>> I think you will need to use a hook in addition to your normal
>> session database. There are some example hooks in the file
>> "goodies/hooks.txt" in the Radiator 2.17.1 distribution.
>>
>> regards
>>
>> Hugh
>>
>>
>> At 16:48 -0300 01/2/14, Mariano Absatz wrote:
>> >Hi people,
>>
>> >
>> >We are having trouble with stale records in our SessionDatabase.
>> >
>> >The NAS is a Nortel Shasta that doesn't seem to have a reasonable means
>> >of being queried about a particular Acct-Session-Id or Username/Framed-IP-
>> >Address.
>> >
>> >We started using Ping, but it seems to be giving addresses on a FIFO
>> >basis, so they are almost immediatly re-used making this method useless.
>> >
>> >The people at Nortel say that they can configure it so it sends Acct-
>> >Interim-Update packets every <N> minutes.
>> >
>> >What we could do is to catch every Acct-Interim-Update packet and make an
>> >update on the SessionDatabase record's Timestamp.
>> >
>> >Now, if we have a user trying to authenticate and according to our
>> >SessionDatabase it would exceed it's Simultaneous-Use value, we could
>> >check every record for this user and if the Timestamp is older than <N>
>> >minutes + 10% (or something like that), we consider it invalid and allow
>> >the user in again.
>> >
>> >How would I do this?
>> >
>> >That is, as there is an AddQuery for an Acct-Start and a DeleteQuery for
>> >an Acct-Stop, I would need to use a kind of "UpdateQuery" for an Acct-
>> >Interim-Update. How can I do this?
> > >
>> >Where should I handle the Simultaneous-Use check? That is, now I simply
>> >set a NasType in the Shasta's <Client> entry. How can I use an arbitrary
>> >perl function for this?
>> >
>> >Thanx.
>> >--
>> >Baby
>> >
>> >--
>> >PS: If one of the Shasta users out there is handling lost Acct-Stop
>> >packets in some other way, I would very much like to know... as we are a
>> >third party and not the ISP itself, we don't have direct access to the
>> >Nortel people.
>> >
>> >
>> >
>> >===
>> >Archive at http://www.starport.net/~radiator/
>> >Announcements on [EMAIL PROTECTED]
>> >To unsubscribe, email '[EMAIL PROTECTED]' with
>> >'unsubscribe radiator' in the body of the message.
>>
>> --
>>
>> NB: I am travelling this week, so there may be delays in our correspondence.
>>
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
>> Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
>>
>> ===
>> Archive at http://www.starport.net/~radiator/
>> Announcements on [EMAIL PROTECTED]
>> To unsubscribe, email '[EMAIL PROTECTED]' with
>> 'unsubscribe radiator' in the body of the message.
--
NB: I am travelling this week, so there may be delays in our correspondence.
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
