(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.
Re: (RADIATOR) snmpget fro TotalControlSNMP
Hi there! Could you please try running the above query by hand from the command line to verify that it is working, and if it is please send me the output. Yes, running it from command line give the same error. Cheers! * Sajari Bin Sarkan * SingNet Network Support * * Hello SaJaRi - On Mon, 25 Sep 2000, SaJaRi wrote: Hi there! I'm trying to limit Maxsession by using SNMP to our NAS. We are using TotalControl Hyper Arc running ver 4.1.59. Already successfully download and compiled ucd-snmp. But i have problem limiting the user to just one session. There's seems to be the problem with the snmpget to the NAS. He's the error that i get: Fri Sep 22 16:30:51 2000: DEBUG: Checking if user is still online: TotalControlSNMP, userid, 165.21.xx.xx, 280, 18284546 165.21.xx.xx Fri Sep 22 16:30:51 2000: DEBUG: Running command `/usr/local/bin/snmpget 165.21.62.254 X .iso.org.dod.internet.private.enterprises.429.4.2.1.140.1.2.8.49.56.50.56.52.53.52.54` EError in packet Reason: (genError) A general failure occured thanks 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) Getting rid of Alive records
Hello Aaron - On Tue, 26 Sep 2000, [EMAIL PROTECTED] wrote: I am using a MwSQL DB to authenticate and log accounting requests. I would like to only get starts and stops and no alives because they clutter up my DB. How can I configure that?? I currently have one realm for DEFAULT and and AuthBySQL clause in it. Any assitance would be appreciated. Here is one way to do it: # configuration to log accounting starts and accounting stops only # first AuthBy does accounting only (note empty AuthSelect) # second AuthBy does authentication only (note empty AccountingTable) # second AuthBy will also acknowledge accounting alives AuthBy SQL Identifier SQLAccounting DBSource DBUsername DBAuth . AuthSelect AccountingTable ACCOUNTING AcctColumnDef . ... /AuthBy AuthBy SQL Identifier SQLAuthentication DBSource DBUsername DBAuth . AuthSelect select ... AuthColumnDef . ... AccountingTable /AuthBy # configure first Handler for accounting # second Handler for authentication Handler Acct-Status-Type = /Start|Stop/ AuthBy SQLAccounting /Handler Handler AuthBy SQLAuthentication /AuthBy If you have any questions please ask. 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) User name as parameter to URL in AddToReply?
At 10:11 26/09/00 +1100, Hugh Irvine wrote:
I must apologise to you, as it does appear that there is a problem with
radacct.cgi and SQL databases in secure mode. I am very sorry that you have
spent a rather frustrating time trying to make this work.
No problem, that was part of discovering Radiator... and PHP :-)
FF.
This PHP script extracts user infos and displays them in a table (for each
session, its date + time, length, bytes sent/received; at the bottom, total
time spent + bytes sent/received since the first connection.)
http://www.acme.com/index.php3?username=jdoepasswd=secret
HTML
FONT FACE="Arial,sans-serif"
?
print("H1Statistiques connexion $username/H1");
setlocale ("LC_TIME", "fr_FR");
$host="localhost";
$user="root";
$password="test";
$db = mysql_connect($host,$user,$password);
mysql_select_db("radius",$db);
//Vérifier que mdp passé ds URL est correcte
$localpasswd = mysql_query("SELECT PASSWORD FROM SUBSCRIBERS WHERE
USERNAME like '$username'",$db);
$row = mysql_fetch_array($localpasswd);
$localpasswd = $row["PASSWORD"];
if ($localpasswd != $passwd) {
printf("Mot de passe incorrecte.P");
} else {
$result = mysql_query("SELECT * FROM ACCOUNTING WHERE
USERNAME like '$username'",$db);
//additionner toutes les valeurs du champ ACCTSESSIONTIME
pour obtenir total cumulé
printf("TABLE BORDER WIDTH=100%%");
printf("TR");
printf("TD WIDTH=25%%BDate session/B/TD");
printf("TD WIDTH=25%%BDurée session/B/TD");
printf("TD WIDTH=25%%BOctets TX/B/TD");
printf("TD WIDTH=25%%BOctets RX/B/TD");
printf("/TR");
while ($myrow = mysql_fetch_array($result)) {
$connexion += $myrow["ACCTSESSIONTIME"];
$inbytes += $myrow["ACCTINPUTOCTETS"];
$outbytes += $myrow["ACCTOUTPUTOCTETS"];
if ($myrow["ACCTSESSIONTIME"]) {
printf("TR");
printf("TD WIDTH=40%%%s/TD",strftime
("%c", $myrow["TIME_STAMP"]) );
if ($myrow["ACCTSESSIONTIME"] 3600):
printf("TD WIDTH=20%%%01.2f
heures/TD",$myrow["ACCTSESSIONTIME"] / 3600);
elseif ($myrow["ACCTSESSIONTIME"] 60):
printf("TD WIDTH=20%%%01.2f
minutes/TD",$myrow["ACCTSESSIONTIME"] / 60);
else :
printf("TD WIDTH=20%%%01.2f
secondes/TD",$myrow["ACCTSESSIONTIME"]);
endif;
#printf("TD
WIDTH=20%%%s/TD",$myrow["ACCTSESSIONTIME"]);
printf("TD
WIDTH=20%%%s/TD",$myrow["ACCTINPUTOCTETS"]);
printf("TD
WIDTH=20%%%s/TD",$myrow["ACCTOUTPUTOCTETS"]);
printf("/TR");
}
}
printf("/TABLE");
if ($connexion 3600):
printf("FONT COLOR=\"#3600FF\"Total connexion =
%01.2f heure(s)/FONTBR",$connexion / 3600);
elseif ($connexion 60):
printf("FONT COLOR=\"#3600FF\"Total connexion =
%01.2f minute(s)/FONTBR",$connexion / 60);
else:
printf ("FONT COLOR=\"#3600FF\"Total connexion =
%01.2f seconde(s)/FONTBR",$connexion);
endif;
printf("FONT COLOR=\"#3600FF\"Total octets envoyés = %s
octets/FONTBR",number_format($inbytes,0,",","."));
printf("FONT COLOR=\"#3600FF\"Total octets reçus = %s
octets/FONTP",number_format($outbytes,
0,",","."));
printf("PPCENTERa
href=\"http://www.cablewanadoo.com\"Wanadoo/A/CENTER");
}
setlocale ("LC_TIME", "C");
?
/FONT
/HTML
===
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) Radiator proxying and NAT
Hello Andrew - On Tue, 26 Sep 2000, Andrew Pollock wrote: -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Monday, September 25, 2000 12:17 PM To: Andrew Pollock; [EMAIL PROTECTED] Subject: Re: (RADIATOR) Radiator proxying and NAT Hello Andrew - On Mon, 25 Sep 2000, Andrew Pollock wrote: Hi, I'm currently troubleshooting a curious problem with Radiator proxying to a second Radiator server that is behind a firewall and is having address translation performed on it. The Radiator server doing the proxying is on the Internet, and the Radiator server being proxied to has a private IP address and a fixed public address is translated to that private IP address. Translation is occuring some of the time, but not consistently, and it's naturally causing all sorts of problems. The problem is going have to be the firewall, but I'm wondering if anything Radiator is doing isn't helping either. One thing I noticed is Radiator is proxying on the packets with a high source port (not 1645). I'm pretty sure that previously I've seen RADIUS servers do all the talking in all directions on port 1645, is this the case? As far as I know, radius clients (which is what Radiator is when acting as a proxy) use high source port numbers when sending requests. The only time we have seen something different (ie. broken) is with some versions of GRIC on NT, which don't reply to the source port as sent in the request. Someone else on the list may have other comments. Hi again, I've done a little bit more research and noticed the following: NAS (outside firewall) talking to RADIUS (Radiator) server (inside firewall) The NAS will change it's source port (the high port) with each new request. Retransmitted requests all use the same source port as the original request. Everything works fine with the firewall and the NATing. Radiator server (outside firewall) talking to Radiator server (inside firewall) The Radiator server outside the firewall changes it's source port every minute or so. Multiple different requests are sent to the other Radiator server on the same source port. The first request is NATed correctly, the subsequent requests are not. Once the Radiator server outside the firewall changes it's source port again, that first request is also NATed successfully, the rest are not. How hard is it going to be to change Radiator to use a new source port for each request that it proxies? Your description is most curious, as Radiator opens a socket and then keeps using it forever. How are you starting radiusd? And what hardware/software platform are you running on? In any case, it sounds like you should fix the firewall. 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) Radiator proxying and NAT
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 26, 2000 6:39 PM
To: Andrew Pollock; [EMAIL PROTECTED]
Subject: RE: (RADIATOR) Radiator proxying and NAT
Hello Andrew -
On Tue, 26 Sep 2000, Andrew Pollock wrote:
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 25, 2000 12:17 PM
To: Andrew Pollock; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Radiator proxying and NAT
Hello Andrew -
On Mon, 25 Sep 2000, Andrew Pollock wrote:
Hi,
I'm currently troubleshooting a curious problem with Radiator
proxying to a
second Radiator server that is behind a firewall and is
having address
translation performed on it.
The Radiator server doing the proxying is on the Internet, and
the Radiator
server being proxied to has a private IP address and a fixed
public address
is translated to that private IP address.
Translation is occuring some of the time, but not
consistently, and it's
naturally causing all sorts of problems. The problem is going
have to be the
firewall, but I'm wondering if anything Radiator is doing
isn't helping
either. One thing I noticed is Radiator is proxying on the
packets with a
high source port (not 1645). I'm pretty sure that
previously I've seen
RADIUS servers do all the talking in all directions on port
1645, is this
the case?
As far as I know, radius clients (which is what Radiator is when
acting as a
proxy) use high source port numbers when sending requests. The
only time we
have seen something different (ie. broken) is with some versions
of GRIC on NT,
which don't reply to the source port as sent in the request.
Someone else on the list may have other comments.
Hi again,
I've done a little bit more research and noticed the following:
NAS (outside firewall) talking to RADIUS (Radiator) server
(inside firewall)
The NAS will change it's source port (the high port) with each
new request.
Retransmitted requests all use the same source port as the
original request.
Everything works fine with the firewall and the NATing.
Radiator server (outside firewall) talking to Radiator server (inside
firewall)
The Radiator server outside the firewall changes it's source port every
minute or so. Multiple different requests are sent to the other Radiator
server on the same source port. The first request is NATed
correctly, the
subsequent requests are not. Once the Radiator server outside
the firewall
changes it's source port again, that first request is also NATed
successfully, the rest are not.
How hard is it going to be to change Radiator to use a new
source port for
each request that it proxies?
Your description is most curious, as Radiator opens a socket and
then keeps
using it forever. How are you starting radiusd? And what hardware/software
platform are you running on?
In any case, it sounds like you should fix the firewall.
Hi Hugh,
We're running Radiator under Solaris 7 on a Sun Ultra 5.
I'm pushing for the firewall to be fixed, it would help if Radiator behaving
exactly the same way as a NAS did, so the firewall people can't point the
finger at it. (Note, NASes talking through the firewall in exactly the same
manner Radiator is are not experiencing any problems whatsoever).
We're starting Radiator like so, on bootup:
PATH=/usr/bin:/bin:/usr/local/bin
case $1 in
'start')
/usr/local/bin/radiusd
rc=$?
;;
'stop')
kill `cat /var/run/radiusd.pid`
rc=$?
;;
*)
echo "usage: $0 {start|stop}"
exit 1
;;
esac
exit ${rc}
I provide a packet dump of the typical behaviour if you like...
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.
(RADIATOR) how many realms and/or handles can i use?
The subject is my question: how many realms and/or handles can i use? thank you Jesus M Diaz [EMAIL PROTECTED] Telia Iberia, S.A. Planificación y Diseño de Red Tfno: +34 91 623 2909 Fax: +34 91 623 2950 === 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) Radiator and Infranet
Has anyone ever gotten Radiator to work with Infranet in leu of their pathetic Radius server? If so, did you write your own AuthBy module for Infranet? Did it take a long time? Any replies are most appreciated... thanks! - 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.
Re: (RADIATOR) Stop Responding
Hugh, Think i keyed onto the problem already, so im goign to hold off. The one change that has been made was to start limited simultaneous usage, with DBM and with BayFinger as the NasTYPE. I believe the fingers were backing up, or slow to respond and were the culprit. After switching to Bay, (snmp version), its run consitantly overnight and thismorning on the problem server. The one other possibilty is the 10bT link between the 2 radius servers, sharinf an NFS link to the SessionDatabase file, perhaps a file locking problem. The computer having the problems is the one with the actual local file however, so i wouldnt think its nfs access time problems, as that would show on the other serer that actually has to write to the file over the network. If it continues to behave strangely ill send over the configs requested. Thanks much. -- Ron Hensley ([EMAIL PROTECTED]) CCNA #10082337 Network Administrator - ICNet Internet Services -- On Tue, 26 Sep 2000, Hugh Irvine wrote: Hello Ron - On Tue, 26 Sep 2000, Ron Hensley wrote: Ive had a strange occurance today on one of my radius servers. It just stops responding though its still running after being up no more then 5 minutes. Stopped/Started many times, a few times with trace level 4 for heavy debug info. Nothing... just stops apparantly in the middle of logging someone in. Its been working fine for the week ive been using it. At one point i noticed my server getting slow as well, and TOP showed the radiusd taking up 25% CPU resources. Any hints on how to track down what could be making it hang? Could you please send me what version of Perl you are using, what version of Radiator, and what hardware and software platform you are running on. I will also need to see a copy of your configuration file (no secrets), together with the trace 4 debug. thanks 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) Stop Responding
Have you considered a diffrent database? We run 5 radius servers off one database with no issues. -Original Message- From: Ron Hensley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 26, 2000 7:38 AM To: Hugh Irvine Cc: [EMAIL PROTECTED] Subject: Re: (RADIATOR) Stop Responding Hugh, Think i keyed onto the problem already, so im goign to hold off. The one change that has been made was to start limited simultaneous usage, with DBM and with BayFinger as the NasTYPE. I believe the fingers were backing up, or slow to respond and were the culprit. After switching to Bay, (snmp version), its run consitantly overnight and thismorning on the problem server. The one other possibilty is the 10bT link between the 2 radius servers, sharinf an NFS link to the SessionDatabase file, perhaps a file locking problem. The computer having the problems is the one with the actual local file however, so i wouldnt think its nfs access time problems, as that would show on the other serer that actually has to write to the file over the network. If it continues to behave strangely ill send over the configs requested. Thanks much. -- Ron Hensley ([EMAIL PROTECTED]) CCNA #10082337 Network Administrator - ICNet Internet Services -- On Tue, 26 Sep 2000, Hugh Irvine wrote: Hello Ron - On Tue, 26 Sep 2000, Ron Hensley wrote: Ive had a strange occurance today on one of my radius servers. It just stops responding though its still running after being up no more then 5 minutes. Stopped/Started many times, a few times with trace level 4 for heavy debug info. Nothing... just stops apparantly in the middle of logging someone in. Its been working fine for the week ive been using it. At one point i noticed my server getting slow as well, and TOP showed the radiusd taking up 25% CPU resources. Any hints on how to track down what could be making it hang? Could you please send me what version of Perl you are using, what version of Radiator, and what hardware and software platform you are running on. I will also need to see a copy of your configuration file (no secrets), together with the trace 4 debug. thanks 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. === 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) SNMP, security and performance idea?
Have the Radiator folks considered using the Perl Net::SNMP module instead of an external snmpget program? There are many advantages to this approach; for one thing, you don't have to run an external program as Net::SNMP is written fully in Perl. That improves performance by eliminating a fork, as well as improving security and reliability by pulling the SNMP code into the daemon itself. For people who use the SessionDatabase feature, this would be a huge benefit... :-) - 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.
(RADIATOR) HOWTO?: AUTH {failed,accepted} in {logfile,syslog}
Hi, howto to log the auth failure or auth accepted into a logfile or syslog ? And howto log a line for each ACCT packet received ? Any help would be appreciated. TIA, /canau -- -- === 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) how many realms and/or handles can i use?
Hello Jesús - On Tue, 26 Sep 2000, Jesús M Díaz wrote: The subject is my question: how many realms and/or handles can i use? There is no limit in Radiator on the number of Realms or Handlers that you can use. However there are some considerations to keep in mind. Realms are stored in a table that is indexed by the Realm name, so finding a Realm to process a particular radius request is very quick and efficient (just a single table lookup). Handlers on the other hand are stored in a linear list, and the tests in the Handler definitions are evaluated for each Handler in sequence until the correct one is found to process a radius request. This needs to be considered if you have a large number of different Handlers. There is also a special form of Handler that can be used if you have the case of dealing with a large number of identical Handler clauses, such as Called-Station-Id for VPDN or wholesale applications. In this case, have a look at the module "CalledStationId.pm" in the goodies directory to see how to build this special form of Handler. 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) Radiator and Infranet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Lloyd Sent: Tuesday, September 26, 2000 11:51 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) Radiator and Infranet Has anyone ever gotten Radiator to work with Infranet in leu of their pathetic Radius server? If so, did you write your own AuthBy module for Infranet? Did it take a long time? Any replies are most appreciated... thanks! Heh, I'm going to write my own AuthBy module one of these days... We just put Radiator in front of TSM and proxy everything through to it. All the hard stuff is done in Radiator, and TSM just does the final authentication. With creative use of inserting the Class attribute you can "tag" specific packets with Radiator for different authentication in TSM. regards 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) Stop Responding
Hello Ron - On Wed, 27 Sep 2000, Ron Hensley wrote: Hugh, Think i keyed onto the problem already, so im goign to hold off. The one change that has been made was to start limited simultaneous usage, with DBM and with BayFinger as the NasTYPE. I believe the fingers were backing up, or slow to respond and were the culprit. After switching to Bay, (snmp version), its run consitantly overnight and thismorning on the problem server. The one other possibilty is the 10bT link between the 2 radius servers, sharinf an NFS link to the SessionDatabase file, perhaps a file locking problem. The computer having the problems is the one with the actual local file however, so i wouldnt think its nfs access time problems, as that would show on the other serer that actually has to write to the file over the network. I would be very suspicious of running a shared DBM session database over NFS. Radiator does not lock the DBM file, so problems are almost guaranteed. I would strongly suggest that you use an SQL session database instead. 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) Radiator proxying and NAT
Hello Andrew -
Your description is most curious, as Radiator opens a socket and
then keeps
using it forever. How are you starting radiusd? And what hardware/software
platform are you running on?
In any case, it sounds like you should fix the firewall.
Hi Hugh,
We're running Radiator under Solaris 7 on a Sun Ultra 5.
I'm pushing for the firewall to be fixed, it would help if Radiator behaving
exactly the same way as a NAS did, so the firewall people can't point the
finger at it. (Note, NASes talking through the firewall in exactly the same
manner Radiator is are not experiencing any problems whatsoever).
We're starting Radiator like so, on bootup:
PATH=/usr/bin:/bin:/usr/local/bin
case $1 in
'start')
/usr/local/bin/radiusd
rc=$?
;;
'stop')
kill `cat /var/run/radiusd.pid`
rc=$?
;;
*)
echo "usage: $0 {start|stop}"
exit 1
;;
esac
exit ${rc}
I provide a packet dump of the typical behaviour if you like...
I would be interested to see a sequence of packets showing the source port
changing, together with the corresponding Radiator trace 4.
thanks
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) SNMP, security and performance idea?
Hello David - On Wed, 27 Sep 2000, David Lloyd wrote: Have the Radiator folks considered using the Perl Net::SNMP module instead of an external snmpget program? There are many advantages to this approach; for one thing, you don't have to run an external program as Net::SNMP is written fully in Perl. That improves performance by eliminating a fork, as well as improving security and reliability by pulling the SNMP code into the daemon itself. For people who use the SessionDatabase feature, this would be a huge benefit... :-) Yes, its on the to-do list. thanks for the suggestion 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) snmpget fro TotalControlSNMP
Hi there! In that case, the problem is not with Radiator, but with snmpget. It may also be the case that the NAS does not have SNMP configured, or that the community string is incorrect. You will need to make sure that snmpget is working properly before Radiator can use it. The snmp on the NAS was already configured and the community string is correct as i can response with snmpget with other OID. From the perl module it look like the radiator is using the session-ID to determine whether the user is log in or not. The thing is after searching through all the OID i can't find any OID that actually get the session-id for the user connected. Just wondering is there any MIB that i'm missing for the Hyper Arc. Any help is appreciated. Cheers! * Sajari Bin Sarkan * SingNet Network Support * * -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.i mQBtAjc9fI4AAAEDAMx6kkJcuhMq9TJEecb3JaiHe6fHRMlaVX/5Om7eCi2xdONO HfVeuTUryabhb7J2mRgKo7z4YWoNxOdNdDtRVaMfD7H18mdV0KYvlR/+9NAgKGxi UEaOYPJsKNHWCAKV1QAFEbQeU2FKYVJpIDxzYWphcmlAc2luZ25ldC5jb20uc2c+ =gG2n -END PGP PUBLIC KEY BLOCK- On Tue, 26 Sep 2000, Hugh Irvine wrote: Hello SaJaRi - On Tue, 26 Sep 2000, SaJaRi wrote: Hi there! Could you please try running the above query by hand from the command line to verify that it is working, and if it is please send me the output. Yes, running it from command line give the same error. 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) snmpget fro TotalControlSNMP
Hello SaJaRi - On Wed, 27 Sep 2000, SaJaRi wrote: Hi there! In that case, the problem is not with Radiator, but with snmpget. It may also be the case that the NAS does not have SNMP configured, or that the community string is incorrect. You will need to make sure that snmpget is working properly before Radiator can use it. The snmp on the NAS was already configured and the community string is correct as i can response with snmpget with other OID. From the perl module it look like the radiator is using the session-ID to determine whether the user is log in or not. The thing is after searching through all the OID i can't find any OID that actually get the session-id for the user connected. Just wondering is there any MIB that i'm missing for the Hyper Arc. I am afraid we don't have any NAS equipment here, but perhaps someone else on the list knows something about the Hyper Arc. 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) Radiator and Infranet
hmmm... will there be any AuthBy Portal or sumthin in the future? i don't wish to give up Radiator in place of their TSM so i end up forwarding just the accounting packets to their TSM for the moment. i'm trying so hard to keep both database in sync, which is temporary until i get the Portal guys to customize their TSM and inherit the functionalities (*hard stuff* as andrew would describe) i'm currently enjoying with Radiator. Andrew Pollock wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Lloyd Sent: Tuesday, September 26, 2000 11:51 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) Radiator and Infranet Has anyone ever gotten Radiator to work with Infranet in leu of their pathetic Radius server? If so, did you write your own AuthBy module for Infranet? Did it take a long time? Any replies are most appreciated... thanks! Heh, I'm going to write my own AuthBy module one of these days... We just put Radiator in front of TSM and proxy everything through to it. All the hard stuff is done in Radiator, and TSM just does the final authentication. With creative use of inserting the Class attribute you can "tag" specific packets with Radiator for different authentication in TSM. regards 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. -- __ OO- `. Darwin A. Bawasanta [EMAIL PROTECTED] pgp-id: 0x367CADAC * ||| Systems Development Manager SKYCablenet, Inc. L_(_/ Ofc: +63 32 253-6677 Mobile: +63 917 486-5033 |||== ((_| "If the facts don't fit the theory, change the facts." === 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.
