Hello Alexey -
At 20:40 +0500 01/3/31, Alexey A. Shavaldin wrote:
>Hello !
>
>I have a question of such a case:
>
>While looking at my RADLOG table, I've found messages about "sessions gone
>away" . They occur not very frequently, but they led me to a decision to look
>through my trace 4 logs. And I've found, that only for these records there're
>corresponding entries in my logs, that Start packets arrive AFTER Stop
>records from NASs of different types (Versalar8000, Cisco, USRTotalControl).
>So it confuses my double simult checking with SNMP, because entries in my
>RADONLINE table about the user are inserted after HIS LOGOUT. So it reflects
>in hanged sessions in RADONLINE and leads to improper information about users
>online.
>
>What can be the reason of such late Start packets (they mostly arrive after
>10 seconds after Stop packets) ? Is there any true solution to deal with this
>problem ?
It sounds very much to me like the initial Start record has been lost
for some reason, and you are getting a retry after the actual session
has ended (a very short session less than 10 seconds). Your NAS
equipement is set for 10 second timeout before retrying a request?
Unfortunately this is the nature of a protocol based on UDP, however
you can adjust the timeouts to be more aggressive with retries.
Note that Radaitor always does a "Delete" from the session database
whenever a Start record is received for a particular NAS and Port
number, so the hung session should only stay in the session database
until the next login arrives for that NAS and Port number.
>I have such kind of a proposal for developers:
>
>I think it will be interesting for some ISPs to include in Radiator a
>feature, which will do simult checking not only for usernames without realms
>and only for usernames with realms, but mixed usernames (with and without
>realms). So, if user xxx is online and his simult is equal to 1, the next
>user with realm xxx@x will be rejected. I had to modify my Nas.pm module in
>order to do such checking for my needs (because our company has several
>tariffs for the same user, @p - for proxy, @i - local resources and so on and
>it is of course necessary to do such a kind of checking). This is done
>because SNMP and other second step simult checking is done by means of simple
>comparing of SNMP variable with incoming username ($result eq $name), so if
>xxx firstly comes to the NAS (with simult=1), and then comes the user with
>xxx@x, SNMP tells, that "xxx is not equal to xxx@x", "Session has gone away".
>The fact is that all NASs keep usernames AS-IS (with or without realms), so
>it is impossible to do simult checking for mixed usernames by means of
>standard Nas.pm. In this case it's necessary to cut off realms together with
>"@" from incoming usernames and from SNMP variables obtained. I've done this
>in Nas.pm (in common words, I've put several conditions and regexp`s in
>Nas.pm for my specific NASs). If it is interesting, I could send my
>Nas.pmmodifications.
There are a number of ways of addressing the problem, most of them
based on extending the information held in the session database,
which is why we supply the default schema and give you access to the
SQL queries so you can make any modifications you need to without
touching the base code.
We are always happy to look at contributed code as long as it doesn't
break existing functionality.
>Well, this led me to another question, how can I do simult checking of
>dial-up users, working from NT workstations (their logins at NAS's look like
>" \xxxxx"). Of course, standard RewriteUsernames help, when working with
>authorization and accounting, but not for second step SNMP checking...
I'm afraid I don't understand the problem here - can you elaborate?
regards
Hugh
--
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.
