Chris Keladis wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> I am having a rather peculiar timeout problem with Radiator authenticating
> from an Oracle SQL database..
>
> Firstly, the details..
>
> Solaris 2.6 (sparc) OS
> Radiator 2.16.3
> Oracle 8.0.5 (sparc)
>
> perl 5.005_03
> Digest-MD5 2.12
> DBI 1.14
> DBD Oracle 1.06
> TimeDate 1.10
>
> Install went fine, a 'make test' gave all OK's, Radiator starts up fine,
> and everything hums along..
>
> However, when i use the radpwtest utility to throw a Radius request at it,
> (even a few requests in succession), it gives me an Accept or Reject
> response (based on if i gave it a correct or incorrect password), but about
> a minute after that, the radiusd process dies with "timeout at
> Radius/SqlDb.pm line 265." (Inside sub getOneRow).
>
> A sample session (Trace 5, Sensitive information obfuscated):
>
> # radpwtst -s x.x.x.x -secret mysecret -user test -password test1 -noacct
> sending Access-Request...
> Fri Sep 29 14:37:36 2000: DEBUG: Packet dump:
> *** Received from x.x.x.x port 32838 ....
>
> Packet length = 70
> [...snipped....]
> Code: Access-Request
> Identifier: 156
> Authentic: 1234567890123456
> Attributes:
> User-Name = "test"
> Service-Type = Framed-User
> NAS-IP-Address = 203.63.154.1
> NAS-Port = 1234
> NAS-Port-Type = Async
> User-Password =
> "[<222>h<159><193><30><222>14<254><172><209><234>(<127>J"
>
> Fri Sep 29 14:37:36 2000: DEBUG: Check if Handler should be used to handle
> this request
> Fri Sep 29 14:37:36 2000: DEBUG: Handling request with Handler ''
> Fri Sep 29 14:37:36 2000: DEBUG: Deleting session for test, x.x.x.x, 1234
> Fri Sep 29 14:37:36 2000: DEBUG: Handling with Radius::AuthSQL
> Fri Sep 29 14:37:36 2000: DEBUG: Handling with Radius::AuthSQL
> Fri Sep 29 14:37:36 2000: DEBUG: Query is: select password from subscribers
> where username='test'
>
> Fri Sep 29 14:37:36 2000: DEBUG: Radius::AuthSQL looks for match with test
> Fri Sep 29 14:37:36 2000: DEBUG: Radius::AuthSQL ACCEPT:
> Fri Sep 29 14:37:36 2000: DEBUG: Access accepted for test
> Fri Sep 29 14:37:36 2000: DEBUG: Packet dump:
> *** Sending to x.x.x.x port 32838 ....
> Code: Access-Accept
> Identifier: 156
> Authentic: 1234567890123456
> Attributes:
>
> OK
>
> [...after about 1 minute...]
>
> timeout at Radius/SqlDb.pm line 265.
I was just about to post the fix to this problem; we are using
Solaris/Oracle. The problem I think is in the way Solaris does
alarm(0). The solution is this:
Edit 'radiusd', add (at about line 45):
$SIG{ALRM} = 'IGNORE';
Then edit the SqlDb.pm file in the Radiator dist and wherever you see:
########
$SIG{ALRM} = sub {die "timeout"} unless ($^O eq 'MSWin32');
eval
{
alarm($self->{Timeout}) unless ($^O eq 'MSWin32');
<database code here>
};
alarm(0) unless ($^O eq 'MSWin32');
########
Change it to:
########
eval
{
local $SIG{ALRM} = sub {die "timeout"} unless ($^O eq 'MSWin32');
alarm($self->{Timeout}) unless ($^O eq 'MSWin32');
<database code here>
};
alarm(0) unless ($^O eq 'MSWin32');
########
I think this construct appears four times inside the file.
But what this does, is cancel the alarm, but put in a failsafe "cushion"
of
$SIG{ALRM} = 'IGNORE' just in case the OS doesn't respond to alarm(0) to
cancel the alarm.
Hope this helps!
- D
<[EMAIL PROTECTED]>
===
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.
