Right now basically I have radius set to run an external script
(optionally) for people that want to avoid rejecting users based on the
problem of accting packets NOT yet being returned (they are lower
priority and can take several minutes to get in there and log to the
radius server). The exteranl script is a half-assed system call that
simply looks at the return value to either reject, or let them in.
The external script could ping or pmwho the router with
show sesisons etc, right now i use pmwho and it needs about 3-5 seconds to
work. I have an internal timer on radius to time it out after 10 and
just let the user in (i.e. if my system fails it defaults to let them in
and then logs a warning to the log files) so we dont piss em off. But 10
seconds doesnt matter if the pm sends another AUTH request. SHouldn't
the radius deamon DROP the 'duplicate' auth request though while the other
auth request is in session? According to the RFC im not entirely sure.
> >came up with these theoretical limits etc). I have a method that can
> >check to make 100% sure, but needs about 5 seconds on average to query
> >the pms to double check a multiple login etc, and setting my own internal
>
> Im working on the same problem (along with the rest of the radius
> consered world :)). I think you'll experience problems with the sollution
> you're describing. I guess you're logging into the pm and parsing
> the output of a 'show ses'. Imho it would be much easier to ping. The
> possibility of an error (ie someone else has logged in to that
> ip address in between, without you recieving the accounting packet)
> is minimal. The implementation will only need 1 sec. or something
> like that to determine for sure that the user is already logged on.
>
> Sverre Hjelm, EUnet Norway
>