(RADIATOR) AuthRADIUS (non)forking problem

[Damir Dzeko]

Hello,

Using Radiator with AuthRADIUS module to handle requests for GRIC
authentication I noticed strange problems. Although in my 
configuration was specified that handler for that type of request
should fork, no forking occured.

That caused our radiusd to block forever(!). That could be because
some bug exists in Select.pm (in process_timeouts function perhaps?).

Useful information could be that I'm using AuthRADIUS with "Synchronous"
flag set.

I traced bug to AuthRADIUS::handle_request function which overrides
default handle_request function defined in its superclass AuthGeneric.

Other Auth* modules which do not redefine handle_request worked fine
with 'Fork' option set, but this one never forked.

Because of that I added the same piece of code found in
AuthGeneric::handle_request into AuthRADIUS::handle_request

    # Now we might fork before processing the request
    # Should only do this for "slow" authentication methods
    return ($main::IGNORE, 'forked')
	if $self->{Fork} && !$self->handlerFork;

I hope you will include that in new release of Radiator.

Also, it would be of great help if someone could correct the
bug that caused my radiusd to wait forever (almost for one
hour) in this loop:

     while (! defined $p->{RadiusResult})
	{
          ...

	    &Radius::Select::process_timeouts();
	}
     return ($p->{RadiusResult});

During that period users of ISP that I work for could not
connect to our dial-up service and that is certainly something
that should happen never again.

-d

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.