Re: (RADIATOR) finger problem
Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. Cheers. On Jun 11, 10:30am, Ferhat Dilman wrote: Subject: (RADIATOR) finger problem Hi, We are using Radiator 2.13.1 on Solaris with Oracle v8. There are several POP's and we use finger for ghost sessions. We use Ascend TNTs. Radiator is in location Istanbul for example, and one of the POP's are in other city e.g. Ankara. When the line goes down between Istanbul-Ankara, and the user tries to logon in Istanbul, since the user information still on RADONLINE, it tries to check it thru finger and since the line is down, finger WAITS! a longtime thus Radiator does not respond other requests till the finger request is finished (single process that is). Then eventually finger timeouts and the session is deleted from RADONLINE and user is permitted. However this has two problems: 1- User may be still online in Ankara (thus simultanous sessions) 2- finger waits too long and no user auth is accepted till timeout of finger Any solutions to finger problem when the line is down? How can we automatically cancel finger requests if the line is down between POP and Radiator-Host location? Thanks very much, Ferhat === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- End of excerpt from Ferhat Dilman -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 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, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) finger problem
Hi, NasType Ascend and the log: Wed Jun 9 01:13:20 1999: ERR: The internal finger client failed with: Can't con nect to 195.x.x.x: Connection timed out Wed Jun 9 01:13:20 1999: NOTICE: Session for xx at 195.x.x.x:90 has gone away (I have deleted user information and NAS identifier IP address) Thanks, Ferhat -Original Message- From: Mike McCauley [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 12, 1999 1:51 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: 'Tuncay Margilic'; 'Lutfi Yunusoglu' Subject: Re: (RADIATOR) finger problem Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. Cheers. On Jun 11, 10:30am, Ferhat Dilman wrote: Subject: (RADIATOR) finger problem Hi, We are using Radiator 2.13.1 on Solaris with Oracle v8. There are several POP's and we use finger for ghost sessions. We use Ascend TNTs. Radiator is in location Istanbul for example, and one of the POP's are in other city e.g. Ankara. When the line goes down between Istanbul-Ankara, and the user tries to logon in Istanbul, since the user information still on RADONLINE, it tries to check it thru finger and since the line is down, finger WAITS! a longtime thus Radiator does not respond other requests till the finger request is finished (single process that is). Then eventually finger timeouts and the session is deleted from RADONLINE and user is permitted. However this has two problems: 1- User may be still online in Ankara (thus simultanous sessions) 2- finger waits too long and no user auth is accepted till timeout of finger Any solutions to finger problem when the line is down? How can we automatically cancel finger requests if the line is down between POP and Radiator-Host location? Thanks very much, Ferhat === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- End of excerpt from Ferhat Dilman -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 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, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) finger problem
On Fri, 11 Jun 1999, Mike McCauley wrote: Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. The BIG problem isn't deleting the user, it is the HUGE delay that occurs while Radiator is trying to verify the user. This stops all other authentications, and when you are running a lot of ports it is disastrous. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) finger problem
One quick solution would be to write your own finger client for Radiator to run. It could do things like: use a shorter timeout remember the state of the line from previous calls etc. On Fri, 11 Jun 1999, Stephen Roderick wrote: On Fri, 11 Jun 1999, Mike McCauley wrote: Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. The BIG problem isn't deleting the user, it is the HUGE delay that occurs while Radiator is trying to verify the user. This stops all other authentications, and when you are running a lot of ports it is disastrous. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. Jim [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
