Re: (RADIATOR) Can't get PEAP to work, need help.
--On mardi 24 juin 2003 09:26 +1000 Mike McCauley [EMAIL PROTECTED] wrote: Hello Jeremy, thanks for the full log. Looks like Radiator is not seeing a completed client hello from your client: its still waiting for the client hello to be closed off. This is very puzzling: your client is behaving differently to other clients we have observed. What PEAP client are you using? Well, this is quite strange as I use both Windows2000 client (hotfix from microsoft) and Funk Odyssey client, giving the same bad result. Maybe the source of the problem could be the AP (Cisco 1200) or the client card (Orinoco, one of the first Lucent ones indeed) ? -- Jerome Fleury === 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.
Re: (RADIATOR) Can't get PEAP to work, need help.
Hello Jerome, On Tue, 24 Jun 2003 08:32 pm, Jerome Fleury wrote: --On mardi 24 juin 2003 09:26 +1000 Mike McCauley [EMAIL PROTECTED] wrote: Hello Jeremy, thanks for the full log. Looks like Radiator is not seeing a completed client hello from your client: its still waiting for the client hello to be closed off. This is very puzzling: your client is behaving differently to other clients we have observed. What PEAP client are you using? Well, this is quite strange as I use both Windows2000 client (hotfix from microsoft) and Funk Odyssey client, giving the same bad result. Maybe the source of the problem could be the AP (Cisco 1200) or the client card (Orinoco, one of the first Lucent ones indeed) ? Hmm, its possible. Do you have the latest firmware in both the AP and the client card? Is you AP configured for unusually large or small MTUs? Around 1100 would be about normal for an AP. -- Jerome Fleury -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS etc. === 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.
Re: (RADIATOR) Can't get PEAP to work, need help.
Hello Jerome, On Tue, 24 Jun 2003 08:32 pm, Jerome Fleury wrote: --On mardi 24 juin 2003 09:26 +1000 Mike McCauley [EMAIL PROTECTED] wrote: Hello Jeremy, thanks for the full log. Looks like Radiator is not seeing a completed client hello from your client: its still waiting for the client hello to be closed off. This is very puzzling: your client is behaving differently to other clients we have observed. What PEAP client are you using? Well, this is quite strange as I use both Windows2000 client (hotfix from microsoft) and Funk Odyssey client, giving the same bad result. Maybe the source of the problem could be the AP (Cisco 1200) or the client card (Orinoco, one of the first Lucent ones indeed) ? OK, I have just retested here with the latest Odyssey 2.0 client and Windows 2000. I can see that the latest Odyssey client does in fact act differently on 2000, nevertheless Radiator worked ok here with it with a successful authentication So now I am back to wondering why Radaitor did not respond to the client hello. Normally it responds with the server certificate. I have looked closely again at your log file and I see something else strange: Mon Jun 23 14:04:09 2003: DEBUG: EAP TLS SSL_accept result: -1, 2, 8465 Mon Jun 23 14:04:09 2003: ERR: jeje - want read Mon Jun 23 14:04:09 2003: ERR: EAP TLS error: -1, 2, 8465, it seems not to have recognised that reason 2 is WANT_READ and instead reported an error. This indicates that there is a problem with either the openssl install oor the Net_SSLeay install. Im sorry I did not see this before. You mentioned previously that you installed the 'latest' openssl but I think you did not say which version. Here we use openssl 0.9.7 and Net_SSLeay 1.22. Caution: openssl 0.9.7 behaves differntly to older version in that it installs it libs and headers in a different place (defaults to /usr/local/ssl). If you have an older version or an RPM installed version, its possible that Net_SSLeay will link with the wrong version. I usually let openssl install in its default place (/usr/local/ssl) then configure Net_SSleay to use it with perl Makefile.PL /usr/local/ssl I strongly suggest you : 1. Ensure there are no old versions of ssl, openssl or Net_SSLeay installed on your host. 2. Compile and install openssl 0.9.7 3. Compile and install Net_SSLeay 1.22 (using the Makefile.PL /usr/local/ssl arg above) Cheers. -- Jerome Fleury === 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. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS etc. === 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) Access-Request packet length limit for Radiator
Title: Message Dear Sirs,We are using Radiator as a Radius Proxy server between our Cisco 5300 Access-Servers and CiscoSecure CSU (2.3.6.1) AAA server in authenticating users for several network services, but mainly for ppp dialup connection.Our dialup users have per-user access-lists which are received by the access-server when a user establishes a ppp connection. This occurs during the authorization process right after authentication.These access-lists get larger in time. We had problems with some of our users which had longer access-lists. They were geting authenticated but could not reach anywhere on the network. When we examined the problem on our Cisco access-servers we saw that their access-list was not fully downloaded to the NAS.The last line is cut from some point. When we remove the last line from the access-list , the problem disappears. Access-accept packet which is received from the proxy radius (which is Radiator) is exactly 8192bytes in size.When we remove the Radiator server from operation and establish AAA connections directly between access-server and CiscoSecure CSU , we receive the full access-list on the NAS, and the access-accept packet is larger than 8192bytes.This shows that the CiscoSecure CSU server and the Cisco NAS does not limit the access-list size (or the authorization packet).Is there such a limit on the Radiator server ?When we increase the log level of the Radius server and check the logfile we see that the radiator says: received packet is 8192 bytes long. This is a part of the log file :Tue Jun 24 14:20:02 2003: DEBUG: Packet dump:*** Received from 193.243.216.8 port 1645 Packet length = 7501 4f 00 4b 5b 79 33 9e f5 d8 6a 8e 76 7a 83 d32a 11 58 0b 04 06 c1 f3 d8 08 3d 06 00 00 00 0001 19 74 65 73 74 73 65 72 74 61 6e 40 6d 61 696c 2e 6b 6f 63 2e 6e 65 74 02 12 91 43 78 1d 3d6b f9 ef 2a 4d d6 21 fc a2 f2 abCode: Access-RequestIdentifier: 79Authentic: [y3158245216j142vz131211*17X11Attributes: NAS-IP-Address = 193.243.216.8 NAS-Port-Type = Async User-Name = "[EMAIL PROTECTED]" User-Password = "145Cx29=k249239*M214!252162242171"Tue Jun 24 14:20:02 2003: DEBUG: Handling request with Handler ''Tue Jun 24 14:20:02 2003: DEBUG: Deleting session for [EMAIL PROTECTED], 193.243.216.8,Tue Jun 24 14:20:02 2003: DEBUG: Handling with Radius::AuthRADIUSTue Jun 24 14:20:02 2003: DEBUG: Packet dump:*** Sending to 195.87.1.231 port 1645 Packet length = 7501 53 00 4b 5b 79 33 9e f5 d8 6a 8e 76 7a 83 d32a 11 58 0b 04 06 c1 f3 d8 08 3d 06 00 00 00 0001 19 74 65 73 74 73 65 72 74 61 6e 40 6d 61 696c 2e 6b 6f 63 2e 6e 65 74 02 12 91 43 78 1d 3d6b f9 ef 2a 4d d6 21 fc a2 f2 abCode: Access-RequestIdentifier: 83Authentic: [y3158245216j142vz131211*17X11Attributes: NAS-IP-Address = 193.243.216.8 NAS-Port-Type = Async User-Name = "[EMAIL PROTECTED]" User-Password = "145Cx29=k249239*M214!252162242171"Tue Jun 24 14:20:02 2003: DEBUG: Packet dump:*** Received from 195.87.1.231 port 1645 Packet length = 8192Best Regards,ilker AktunaKoc.net Network Services _ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, could not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. _
(RADIATOR) Store RADIUS attributes in LDAP?
The Radiator documentation states that I can store RADIUS attributes in LDAP, and retrieve them with AuthAttrDef or similar methods. But the documentation doesn't discuss what schema to use, or how those attributes should be stored so that Radiator can find them. How are other people doing this? (Is anyone else doing this?) Are you using schema's from OpenRADIUS or FreeRadius, or Netscape Directory Server or the aboba draft? Or are you building your own schema? Thanks! Matt -- Matt Richard Access and Security Coordinator Franklin Marshall College [EMAIL PROTECTED] (717) 291-4157 === 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.
Re: (RADIATOR) Can't get PEAP to work, need help.
--On Tuesday, June 24, 2003 09:58:28 PM +1000 Mike McCauley [EMAIL PROTECTED] wrote:
Hello Jerome,
On Tue, 24 Jun 2003 08:32 pm, Jerome Fleury wrote:
--On mardi 24 juin 2003 09:26 +1000 Mike McCauley [EMAIL PROTECTED] wrote:
Hello Jeremy,
thanks for the full log.
Looks like Radiator is not seeing a completed client hello from your
client: its still waiting for the client hello to be closed off.
This is very puzzling: your client is behaving differently to other
clients we have observed.
What PEAP client are you using?
Well, this is quite strange as I use both Windows2000 client (hotfix from
microsoft) and Funk Odyssey client, giving the same bad result.
Maybe the source of the problem could be the AP (Cisco 1200) or the client
card (Orinoco, one of the first Lucent ones indeed) ?
OK, I have just retested here with the latest Odyssey 2.0 client and Windows
2000. I can see that the latest Odyssey client does in fact act differently
on 2000, nevertheless Radiator worked ok here with it with a successful
authentication
So now I am back to wondering why Radaitor did not respond to the client
hello. Normally it responds with the server certificate.
I have looked closely again at your log file and I see something else strange:
Mon Jun 23 14:04:09 2003: DEBUG: EAP TLS SSL_accept result: -1, 2, 8465
Mon Jun 23 14:04:09 2003: ERR: jeje - want read
Mon Jun 23 14:04:09 2003: ERR: EAP TLS error: -1, 2, 8465,
it seems not to have recognised that reason 2 is WANT_READ and instead
reported an error.
This indicates that there is a problem with either the openssl install oor the
Net_SSLeay install.
Im sorry I did not see this before.
No that's me sorry not to have precised this: I added some debug code in the WANT_READ
condition block:
elsif ($reason == ERROR_WANT_READ)
{
$self-log($main::LOG_ERR, jeje - want read, $p);
my $errs = Net::SSLeay::print_errs();
$self-log($main::LOG_ERR, EAP TLS error: $ret, $reason,
$state,
$errs);
$self-eap_failure($p-{rp}, $context);
# Looking for more data, just ack this
}
So that it recognizes WANT_READ well. Sorry for giving you a bad path.
I strongly suggest you :
1. Ensure there are no old versions of ssl, openssl or Net_SSLeay installed on
your host.
No, old older versions are overrided.
2. Compile and install openssl 0.9.7
done.
3. Compile and install Net_SSLeay 1.22 (using the Makefile.PL /usr/local/ssl
arg above)
done (1.23)
At this point, I think I'll try on an other fresh Unix install.
Thanks for your help Mike.
--
Jerome Fleury
===
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.
Re: (RADIATOR) Store RADIUS attributes in LDAP?
Hi Matt, We are storing user information in LDAP. Below is the authby clause we use. To add radius attributes to the ldap entry for the user you simply need to have them in the entry for the user ( same level in our case ). We retrieve static ip addresses for example using the AuthAttrDef. If there is a match for the entry StaticIPaddress on the user a reply-item of Framed-IP-Address is returned. If not, nothing is returned and the reply item does not get added. You can do the same for any radius attribute. AuthAttrDef takes care of mapping together radius attributes and corresponding attributes in LDAP. Hope this helps, Ingvar AuthBy LDAP2 Identifier CheckLDAP NoDefault DefaultSimultaneousUse 1 Host ldaphost.your.network Port 389 HoldServerConnection Timeout 2 FailureBackoffTime 300 Scope one AuthDN cn=Manager,cn=ldaphost AuthPassword ldappassword BaseDN cn=People,cn=domain1,cn=Virtual Domains,cn=ldaphost UsernameAttr uid PasswordAttr clearTextPassword SearchFilter ((serviceStatus=Active)(%0=%w)(|(IPConnectionType=ISDNPLUS)(IPConnectionTyp e=ADSL))) AuthAttrDef StaticIPaddress,Framed-IP-Address,reply AddToReply Framed-Protocol = PPP,\ Framed-IP-Netmask = 255.255.255.255, \ Framed-Routing = None, \ Service-Type = Framed-User, \ Framed-MTU = 1500, \ Framed-Compression = Van-Jacobson-TCP-IP /AuthBy Ingvar Bjarnason Engineer/Data division Iceland Telecom - Original Message - From: Matt Richard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 2:27 PM Subject: (RADIATOR) Store RADIUS attributes in LDAP? The Radiator documentation states that I can store RADIUS attributes in LDAP, and retrieve them with AuthAttrDef or similar methods. But the documentation doesn't discuss what schema to use, or how those attributes should be stored so that Radiator can find them. How are other people doing this? (Is anyone else doing this?) Are you using schema's from OpenRADIUS or FreeRadius, or Netscape Directory Server or the aboba draft? Or are you building your own schema? Thanks! Matt -- Matt Richard Access and Security Coordinator Franklin Marshall College [EMAIL PROTECTED] (717) 291-4157 === 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. === 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.
RE: (RADIATOR) Radiator Radar conflict
Has any additional information become available on this I have requested that our people, restrict their use of radar, until further notice Cheers Chris. -Original Message-From: Hugh Irvine [mailto:[EMAIL PROTECTED]Sent: Friday, 20 June 2003 9:57 AMTo: Dave Birkbeck; [EMAIL PROTECTED]Cc: 'Herman verschooten'; [EMAIL PROTECTED]Subject: Re: (RADIATOR) Radiator Radar conflict Hello Dave, Hello Herman - Could you both please send us more details including Radiator version hardware/software platform, Perl version and any other debugging information that you have available. The output from Perl when the crash occurs would also be very helpful. I have copied Mike on this mail as we would like to fix whatever is wrong. thanks and regards Hugh On Friday, Jun 20, 2003, at 07:19 Australia/Melbourne, Dave Birkbeck wrote: Ive noticed the same problem. Sometimes it will crash within just a couple minutes of debugging and other times it takes longer. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf OfHerman verschooten Sent: Thursday, June 19, 2003 11:18 AM To: [EMAIL PROTECTED] Subject: (RADIATOR) Radiator Radar conflict Hi, I have noticed that keeping Radar open all the time on debug-logging sometimes freezes Radiator... Has anyone else noticed this? Just closing Radar start everything up again. Herman NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
Re: (RADIATOR) Radiator Radar conflict
Hello Chris - I have asked both Dave and Herman for further details and I'm awaiting their replies. Have you had any problems or is this just a precaution? We have never seen this reported previously so if you have been using Radar successfully until now I doubt that you are likely to have any difficulties. As always, please report any problems as we want to make sure they get fixed. regards Hugh On Wednesday, Jun 25, 2003, at 08:15 Australia/Melbourne, Chris Patterson wrote: Has any additional information become available on this ? I have requested that our people, restrict their use of radar, until further notice ? Cheers Chris. -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED] Sent: Friday, 20 June 2003 9:57 AM To: Dave Birkbeck; [EMAIL PROTECTED] Cc: 'Herman verschooten'; [EMAIL PROTECTED] Subject: Re: (RADIATOR) Radiator Radar conflict Hello Dave, Hello Herman - Could you both please send us more details including Radiator version hardware/software platform, Perl version and any other debugging information that you have available. The output from Perl when the crash occurs would also be very helpful. I have copied Mike on this mail as we would like to fix whatever is wrong.? thanks and regards Hugh On Friday, Jun 20, 2003, at 07:19 Australia/Melbourne, Dave Birkbeck wrote: Ive noticed the same problem. Sometimes it will crash within just a couple minutes of debugging and other times it takes longer. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf OfHerman verschooten Sent: Thursday, June 19, 2003 11:18 AM To: [EMAIL PROTECTED] Subject: (RADIATOR) Radiator Radar conflict Hi, I have noticed that keeping Radar open all the time on debug-logging sometimes freezes Radiator... Has anyone else noticed this?? Just closing Radar start everything up again. Herman NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
Re: (RADIATOR) Can't get PEAP to work, need help.
Hello Jerome,
On Wed, 25 Jun 2003 01:37 am, Jerome Fleury wrote:
--On Tuesday, June 24, 2003 09:58:28 PM +1000 Mike McCauley
[EMAIL PROTECTED] wrote:
Hello Jerome,
On Tue, 24 Jun 2003 08:32 pm, Jerome Fleury wrote:
--On mardi 24 juin 2003 09:26 +1000 Mike McCauley [EMAIL PROTECTED]
wrote:
Hello Jeremy,
thanks for the full log.
Looks like Radiator is not seeing a completed client hello from your
client: its still waiting for the client hello to be closed off.
This is very puzzling: your client is behaving differently to other
clients we have observed.
What PEAP client are you using?
Well, this is quite strange as I use both Windows2000 client (hotfix
from microsoft) and Funk Odyssey client, giving the same bad result.
Maybe the source of the problem could be the AP (Cisco 1200) or the
client card (Orinoco, one of the first Lucent ones indeed) ?
OK, I have just retested here with the latest Odyssey 2.0 client and
Windows 2000. I can see that the latest Odyssey client does in fact act
differently on 2000, nevertheless Radiator worked ok here with it with a
successful authentication
So now I am back to wondering why Radaitor did not respond to the client
hello. Normally it responds with the server certificate.
I have looked closely again at your log file and I see something else
strange:
Mon Jun 23 14:04:09 2003: DEBUG: EAP TLS SSL_accept result: -1, 2, 8465
Mon Jun 23 14:04:09 2003: ERR: jeje - want read
Mon Jun 23 14:04:09 2003: ERR: EAP TLS error: -1, 2, 8465,
it seems not to have recognised that reason 2 is WANT_READ and instead
reported an error.
This indicates that there is a problem with either the openssl install
oor the Net_SSLeay install.
Im sorry I did not see this before.
No that's me sorry not to have precised this: I added some debug code in
the WANT_READ condition block:
elsif ($reason == ERROR_WANT_READ)
{
$self-log($main::LOG_ERR, jeje - want read, $p);
my $errs = Net::SSLeay::print_errs();
$self-log($main::LOG_ERR, EAP TLS error: $ret,
$reason, $state, $errs);
$self-eap_failure($p-{rp}, $context);
# Looking for more data, just ack this
}
So that it recognizes WANT_READ well. Sorry for giving you a bad path.
OK. I understand now.
If you are convinced the openssl/Net_SSLeay install is OK, its time to look at
your config. Are you testing with the example eap_peap.cfg file, and the test
certificates we supply?
May we see your config file (no secrets)?
I strongly suggest you :
1. Ensure there are no old versions of ssl, openssl or Net_SSLeay
installed on your host.
No, old older versions are overrided.
2. Compile and install openssl 0.9.7
done.
3. Compile and install Net_SSLeay 1.22 (using the Makefile.PL
/usr/local/ssl arg above)
done (1.23)
OK. Tested OK with 1.23 here.
At this point, I think I'll try on an other fresh Unix install.
OK.
Cheers.
Thanks for your help Mike.
--
Jerome Fleury
===
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.
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP etc on Unix, Windows, MacOS etc.
===
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.
Re: (RADIATOR) How to restrict the Dial Up on Bandwith.
Hi, I wonder up to what point you are able to deal with such a log's? We have at the moment around 5.5M records per month in our DSL customers log and to match that to a NetFlow log about 114TB (that's their generated traffic)... huhh How far this kind a solution scales? Anyway, we give (test period at the moment) to one certian site 2Mbps but to any else accoring to the original bandwith (256kbps to 512kbps) but we don't account for ammount of data - everything is flat fee. This feature is basically traffic shaping based on access-lists. Hardware used is Unisphere/Siemens/(and now already)Juniper ERX family. RedBack's will also have that feature for their SMS series by the end of summer and SE (SmartEdge) is already capable of it (I think - haven't tested jet the latest software). Rgds. Toomas Kärner - Original Message - From: Guðbjörn S. Hreinsson [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 22, 2003 1:25 PM Subject: Re: (RADIATOR) How to restrict the Dial Up on Bandwith. We use Cisco Netflow to measure traffic, we exclude certain sites so that traffic does not appear in the logs. We then match radius accounting packets and netflow logs to generate rating data for billing. We don't speed limit customers when they pass their limits, but bill them for the extra download. Rgds, -GSH I am not sure if this soultion is done with Radiator or not. I have noticed many ISP's offering ADSL connections with free traffic to certain web sites. They are also speed limiting customers when they run passed their download limit but not counting the traffic to the free websites. Anyone know how the radius accounting is done. Or does anyone know what product they are using to do this. - === 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. === 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.
