Hello Chris -
>
> >On Thu, 20 Jul 2000, Hugh Irvine wrote:
> >
> > > A better approach to maintaining session database coherency is to use
> > > strict checking of the NAS. This is what the NasType parameter is used
> > > for in the Client clauses (see section 6.4.5 in the Radiator 2.16.1
> > > reference manual). Note that there is a new NasType of "Ping" in
> > > 2.16.1 that doesn't actually query the NAS (via finger, who, snmp or
> > > whatever), but simply pings the IP address (Framed-IP-Address) to see
> > > if it is still there. An additional trick that is useful is to have a
> > > special Handler(s) to catch bogus accounting records, and use a
> > > SessionDatabase INTERNAL in that Handler(s) to keep the bogus records
> > > away from the SQL session database.
> > >
> > > This subject was discussed on the list fairly comprehensively a couple
> > > of months ago, and several customers have reported very good success
> > > with an SQL session database (with a custom DeleteQuery to delete a
> > > record with an IP address and/or a NAS-IP-Address/NAS-Port) and a
> > > NasType of Ping.
>
> I'm sort of unclear on NasType Ping. If it is going to ping the
> dialin client's IP address, and they have a Pipeline router running
> NAT behind it, ping is going to fail since that is a Lucent
> "feature." So isn't this method doomed to failure in a number of
> similar pathological cases?
>
Yes it is, but such is the nature of the beast.
The alternative of course is to use one of the other NasType's.
regards
Hugh
--
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.
