Hello Carles -
I have copied this message to Mike so he can add his comments as well.
For your first point, the behaviour you observe is correct, and the
disadvantage of using strict session limit checking by querying the NAS is
exactly as you describe, however that is the way that Radiator currently
operates.
As has been discussed on the list on numerous occassions, the answer is for
Radiator to be multi-threaded, but until Perl includes production quality
multi-threading support Radiator will continue to be single threaded.
I will let Mike comment on your second point below.
regards
Hugh
On Mon, 11 Sep 2000, Carles Xavier Munyoz Bald� wrote:
> Hi,
> I've been making an study about the way Radiator uses the SNMP to query
> NAS.
> I've discovered that Radiators forks a child, exec the snmpget program
> and then WAITS FOR ITS ANSWER.
> During this WAIT, the Radiator doesn't process any more Access-Request
> or Accounting-Request packets.
> In a busy Radiator system, this could make that the UDP receive queue
> fills up, and the lost of Access/Accounting requests, making that the
> NAS (or proxy) resend radius packets.
>
> I believe that this is a very important bug, because if there is a
> network problem between the Radiator and the NAS, it is possible that
> the users have problems for authenticate. For example, if one of the NAS
> fails, when Radiator makes one SNMP query to this NAS, during 6 seconds
> (the time the snmpget program needs to say timeout) the Radiator will
> not process any radius packet... all the authentication system will be
> stoped for all the NAS network.
>
> Other bug I believe I reported you some time ago, is that when the NAS
> not responds to the SNMP query send by Radiator (snmpget program
> timeout), the Radiator misintrepret this like if the user for wich it
> makes the query is not in that NAS and then elimantes him from the
> Sessions Data Base and allows the new connection with the same username.
> This allows connect more than 1 user with the same username, from
> different NAS and PORT.
> This bug is in the function:
> sub isOnlineAscendSNMP
> {
> my ($name, $nas_id, $nas_port, $session_id, $client) = @_;
>
> return 1 unless &Radius::SNMP::snmpgetprogExists();
>
> my $result = &Radius::SNMP::snmpget($nas_id,
> $client->{SNMPCommunity},
> "$Radius::Nas::AscendMIB.12.2.1.3.$nas_port");
> if ($result =~ /^.*\"([^"]+)".*$/)
> {
> return $1 eq $name;
> }
> return
> }
>
> Are you making a patch for this bugs ?
> When will be a solution for it ?
>
> Greetings and many thanks for your time.
> --
> Carles Xavier Munyoz Bald� / [EMAIL PROTECTED]
> Wanadoo Espa�a
> Dpto. Sistemas / System Department
> Tel: +34 96 5040000 Ext. 40046 - Fax: +34 96 5040047
> http://www.wanadoo.es/
> ---
>
> ===
> 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.
--
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.
