(RADIATOR) Radiator 3.0 possible bug ?
Not sure this is a new feature or a bug. Here is an excerpt on my radius.cfg : SessionDatabase NULL /SessionDatabase SessionDatabase SQL Identifier adsl /SessionDatabase Handler Realm=/\.fsa$/, Client-Identifier=lns AcctLogFileName %L/%R/detail-lns AccountingHandled /Handler Handler Realm=/\.fsa$/ AcctLogFileName %L/%R/detail-lac SessionDatabase adsl AccountingHandled /Handler I happens that both handlers do now use the adsl SessionDatabase. Is this desired ? By adding an identifier null session everything goes back to normal : SessionDatabase NULL Identifier nosess /SessionDatabase Handler Realm=/\.fsa$/, Client-Identifier=lns AcctLogFileName %L/%R/detail-lns SessionDatabase nosess AccountingHandled /Handler -- Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Transpac === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Should Radiator handle RetryTimeout = 0 as a special case ?
The idea behind the title, is to be able to blindly forward and forget a packet to a third host, typically for non reliable recording. Typically this would just concern accounting packets : AuthBy RADIUS Hostmy-unreliable-session-db IgnoreAuthentication IgnoreAccountingResponse RetryTimeout 0 ... RetryTimeout 0 would then mean a special handling in sendHost : - do not update pendingRequests; - do not call add_timeout. Does this make sense ? -- Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Transpac Direction des opérations, CSI Gennevilliers === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Shall BaseDN be a formatted string ?
This is just a philosophical question...
My wish is to be able to do this for my LDAP frontends :
Handler
PreProcessingHook sub { ## set Base1 and Base2 bases on %R }
RewriteUsername s/\@.+$//
AuthBy LDAP2
Hostmyldapserver
AuthDN p=mydn,t=o
AuthPasswordmypassword
BaseDN c=%{GlobalVar:Base1},c=%{GlobalVar:Base2},t=b
...
/AuthBy
/Handler
--
Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Transpac
===
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) Memory leak in 2.16.3 (no LDAP)
I believe there is a severe memory leak in Radiator 2.16.3. The server is configured as a Proxy-Radius only (10 Realms only), no DB_File, no LDAP. Radiusd grows to over 50 MB in around 12 hours. The same configuration on a 2.15 running since July is only 25 MB in size. -- Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Transpac === 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) 2.16.3 error in decode_tunnel_password (Radius.pm:461)
Just gotcha an error here : substr($password, $len) = ''; substr outside of string at /usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm line 461. Modification of a read-only value attempted at /usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm line 461. Investigation under progress for now :(. -- Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Oleane === 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.
Re: (RADIATOR) 2.16.3 error in decode_tunnel_password (Radius.pm:461)
Update to my previous report, I found the cause of this issue. It might happen that a remote site sends an incorrectly encoded tunnel password (or it might just be a wrong secret). As there is no mechanism for verifying the correctness of the decoded block, and typically the length field might have any value. The proposed correction is following : substr($password, $len) = '' if ($len length($password)); This is just a hack, but is there a need to do something more sophisticated, as if the decoded password is wrong, we really don't care about what we are returning and we just need to prevent Radiator from crashing. Christophe Wolfhugel : Just gotcha an error here : substr($password, $len) = ''; substr outside of string at /usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm line 461. Modification of a read-only value attempted at /usr/local/lib/perl5/site_perl/5.005/Radius/Radius.pm line 461. === 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) CHAP-Password : possible bug in AuthGeneric (2.16.3)
I believe there is a bug in handle_request in AuthGeneric.pm :
if (defined $self-{RejectEmptyPassword}
$p-decodedPassword() eq '')
{
$self-log($main::LOG_DEBUG, "$type rejected $user_name because of a
n empty password");
return ($main::REJECT, 'Empty password');
}
The function decodedPassword will return '' in the case of a CHAP-Password
attribute. This is particularly true when using AuthLDAP2 because in its
initialization it forces the value of RejectEmptyPassword to 1.
My current workaround is to comment $self-{RejectEmptyPassword} = 1 out
in AuthLDAP2.pm, but I'm sure that the real solution should be in the
AuthGeneric.pm test.
--
Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Oleane
===
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) Question regarding DupInterval
From the documentation, DupInterval is applied to the client, ie the
host sending the request, eventually an intermediate proxy.
From reading the Client.pm source code I see following :
$self-{RecentIdentifiers}-{$nas_id . $code}[$p-identifier]
$nas_id is there supposed to be the NAS-IP-Address, or if not
available NAS-Identifier, which is possibly not the proxy. Only
if none of these attributes are present $nas_id will contain the IP
address of the Client. The $code identifies the type of request, so
on a standard setup that gives a 256 packets history for each kind of
request.
If my understanding is correct this is somewhat different from what
the documentation as well as the comment at the beginning of Client.pm
say.
Now let's go to my particular situation : I have an central accountng Radius
server which gets all accounting packets from the proxys. Whenever this
machine gets really odd (or just out of CPU) the proxies start doing
retransmissions, and then the NASes also start retransmitting (via
a different proxy). By having a really high DupInterval (19) on this
accounting Radius I reduce the number of duplicate records in the
accounting files on that machine, but my clients won't get their
Accounting-Accept because Radiator believes it comes from the same client.
I would conclude that my design is wrong and that I should reduce the
DupInterval on the accounting Radius a lot and have the scripts who
handle the accounting files manage to eliminate the duplicate. Can
someone more knowledgable confirm me this is the way I should go ?
--
Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Oleane
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
