> With the current implementation (which isn't likely to change) It is
> possible, and not unheard of in the least, for someone to logout and
> log bachk in before before the accounting termination packet gets through.
ACtually, as you know thats the single largest problem. But, i solved it
with a few methods.
What I did was work with the original 1.16 esva radius implementation from
leo@savage.net. I found a few bugs in leo's code (i.e. his code to log
out users when a portmaster reboots or crashes was slightly flawed). My
new version keeps a running-time user database based solely upon what the
radius server recieves in the accounting packets (this is what the esva
radius code does best for the blocking of multiple logins). The key is, to
keep the run-time database clean and up to date. Especially with ISDN
calls that can come in and log within 1/2 a second after a disconection.
My code is designed with an external call (sort of a cheap way out) to
verify if multiple logins are really taking place. Keep in mind, this is
ONLY run in the few instances where a user calls right back after logging
out AND the radius accounting info hasnt yet been received to the server
(and thus the 'running' time database thinks the user is still logged in).
I pass to the external process the username, which NAS and port
they are trying to log into- and any NAS/port combos they online database
thinks its logged into. THe external process can be as simple as a 6 line
bash script to run pmwho (which is what I do), or you couuld write a
'plug-in' to take more info like ip address and ping that (assuming its a
framed ip address).
The real kicker in the code, is the logic/failsafe. I.e., I run a 1 hour
timer inside the deamon that tracks the # of concurrent denied attempts
for unique users that originated from the same pm. After a configured
amount (i have it set to 2) it auto-logs out of the accuonting dbase all
users on that NAS that 'appears' to be flawed. Also, the same is done for
any portmaster that crashed (looks for a 00000000 start card or stop code
from any NAS) and then logs out those users (previously, depending on how
you do your billing, customers on a pm that 'crashed' would never get a
STOP record sent to the radius server, so you loose billible hours. With
this method, you at least get to bill them for time up to the crash of the
server. Keep in mind, network outage can be just as bad on remote pops
(i.e. your network connection fails, but hte pm doesnt reboot but
customers keep coming in and out, and thus no acct packets ever reach your
radius server), but the new logic system will reset the online database
for the remote pops by looking at the # of duplicate login attempts in any
one site in a given time and make 'admin-programible' decisions based on
the # of attempts in a time period.
Anyway, i have it running now here, and have reduced the 'fake' warnings
from the old esva implementation from about 50-60 a day to about 5-6
bonafide attempts last night. My attempts are logged such that i know the
port they are trying to log into, and a 'real time' view (via pmwho) of
which line(s) they are still logged into (so I can see for sure their
sessions are in play when trying to gain access to additional channels).
Lots of other 'logic' in there too, once done ill throw up a diff file
if you want to see it. It seems to work for me, with about 14 portmasters
and 5000 accounts. Your millage might vary ;)
Adam Wills Global 2000 Communications
Director of Networking Systems 1840 Western Ave.
sysadmin@global2000.net Albany, NY, 12203
http://www.global2000.net (518) 452-1465