(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.
Re: (RADIATOR) LDAP2 AuthAttrDef Problem (IMPORTANT)
Hello Richard - On Mon, 04 Sep 2000, Richard Nagelmaeker wrote: Hi, We're having a problem with Radiator checking the LDAP server for an attribute with AuthAttrDef. If I do the following request: (AuthBy LDAP2, Radiator 2.16.3) AuthAttrDef LDAP-Attribute, Radius-Attribute, check It responds fine if the LDAP-Attribute is in the record of the user. If the LDAP-Attribute is not in the users record, Radiator does no check on it and allows access to the user. Where I want the user to be denied access if the LDAP-Attribute is not in his record. Does someone know the solution for this problem? You should use the SearchFilter parameter to define whatever search finlter you require. Have a look at section 6.32.13 in the Radiator 2.16.3 reference manual. I know the answer might be in recent messages of the Radiator Archive, but the webserver seems to be unable to find the right pages for august and september. It works fine for earlier dates though. I have sent a message to the maintainer of the archive site - thanks for bringing the problem to our attention. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === 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) chap encrypted password
Hello Sek Chye - On Mon, 04 Sep 2000, Goh Sek Chye wrote: Hi! Currently we encrypt our subscribers' password. This means that we cannot support CHAP authentication. However, I am now under pressure to support CHAP as well. To support CHAP, I need to store subscribers' password in clear text and I am not comfortable with that. Is there any solution to support CHAP and at the same time store the password encrypted? Unfortunately no, as with CHAP only the encryption is sent for the password, and you need to be able to perform the same encryption at the server end to be able to compare the two encrypted passwords. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === 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) Handler for a set of realms
Hi, Is it currently possible with Radiator to readily have a handler that checks for the realm being in a set of realms? The reason I ask is we have a system here that can theoretically add additional realms that require to be handled at any point in time, and it would be ideal if Radiator could read this from an external file. Hope this makes sense. Andrew === 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) Handler for a set of realms
Hello Andrew - On Tue, 05 Sep 2000, Andrew Pollock wrote: Hi, Is it currently possible with Radiator to readily have a handler that checks for the realm being in a set of realms? The reason I ask is we have a system here that can theoretically add additional realms that require to be handled at any point in time, and it would be ideal if Radiator could read this from an external file. I think you will have to use a PreHandlerHook to check your file, and perhaps set a pseudo-attribute in the request packet that will be used to select the Handler. There are some examples of hooks in the file "goodies/hooks.txt" in the Radiator 2.16.3 release (also included in all recent releases). hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === 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) Handlers and Realms (101)
Hello All, We would like to add a facility to our existing radiator install where a user can dial-in to our access server using a different telephone number and receive different access permissions (eg: maximum session time) As they will be connecting to the same access server I figure we need to setup a handler based on the number they are dialling in to - as the default realm for the access server is already being used. My question is : can I setup a handler just for the called station ID and keep the existing realm whatever or must I change everything to be handled by a handler? Thanks in advance. Brian Morris === 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) Handlers and Realms (101)
Hello Brian - On Tue, 05 Sep 2000, Brian Morris wrote: Hello All, We would like to add a facility to our existing radiator install where a user can dial-in to our access server using a different telephone number and receive different access permissions (eg: maximum session time) As they will be connecting to the same access server I figure we need to setup a handler based on the number they are dialling in to - as the default realm for the access server is already being used. My question is : can I setup a handler just for the called station ID and keep the existing realm whatever or must I change everything to be handled by a handler? You should convert everything to Handlers: Handler Called-Station-Id = .. /Handler Handler Called-Station-Id = .. /Handler Handler Realm = foo.bar .. /Handler Handler Realm = DEFAULT .. /Handler Handler /Handler Note that Handlers are processed in the order they appear in the configuration file, so the more specific must appear before the more general. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === 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.