Hello Teddy -
On Sat, 04 Mar 2000, Teddy Victor, Mercado Rodrigo wrote:
>
> I don't answer, because all this time I was testing the new configuration
> (i.e with DupInterval seted to 60 seconds) but the problem persist. I have
> two Ascend MAX TNT with a total of 10 E1 links (300 dial-up channels) and
> the average of users always conected to internet is between 200 and 250.
>
> In the Max TNT I had seted the accounting timeout in the External-Auth
> profile to 7 seconds, so if the Max don't get an answer within this time,
> it will send a second packet.
>
> I'm using the ODBC option to retrieve and save all information over
> Informix including the RADONLINE table for simultaneous use check.
> I seted the timeout in the MAX TNT to 7 seconds and all duplicates packets
> have the acct-delay-time = 7, and the timestamp of the packet is 7 seconds
> plus the original packet.
>
> I was looking for external causes for the problem (delay in the database,
> etc), but all looks fine.
>
> Any sugestion?
>
The best thing to do now is run Radiator with a Trace 4 so you can see in the
debug output where the delays are occuring. Every entry is timestamped and you
will see at what time the request packet arrives, what happens to the packet,
what interactions occur with the database, etc. You should be able to see from
the timestamps at what stage in the request processing the delays are happening
and from there discover the source of the problem.
You can also send me a copy of the trace output and I will have a look also.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, MacOS X
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
