Re: (RADIATOR) Question about Rodopi?
Title: Re: (RADIATOR) Question about Rodopi? Hello Chairarth - Where are you going to maintain your customer definitions? In Radmin, Rodopi, or both? regards Hugh At 13:49 +0700 01/7/12, Chairarth K wrote: There is any problem if we will use Radmin, Radiator and Rodopi billing at the same time. Regards, Chairath -- NB: I am travelling this week, so there may be delays in our correspondence. 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.
(RADIATOR) Question about Rodopi?
There is any problem if we will use Radmin, Radiator and Rodopi billing at the same time. Regards, Chairath
Re: (RADIATOR) accept all auth-req
Hi Jules Thanks for your advice. Regards, Chairath [EMAIL PROTECTED] wrote: Hi, you can include a group in your Realm like this: AuthBy GROUP_Identifier . . and your group could be compose of two AuthBy authenticators: AuthByPolicy ContinueUntilAccept Identifier GROUP_Identifier AuthBy RADMIN_Identifier AuthBy TEST_Identifier So in that way I think you first will authenticate via RADMIN, and in case of failure, AuthBy TEST will always accept your authentication requests. Test it and tell me if it works. regards, jules -Mensaje original- De: chairarth [mailto:[EMAIL PROTECTED]] Enviado el: lunes 9 de julio de 2001 10:38 Para: radiator Asunto: (RADIATOR) accept all auth-req Hi, In case of Authen by Radmin , how can I config Radiator to accept all authen-requests whenever the SQL Host down. Regards, Chairath ** Noticia legal Este mensaje electrónico contiene información de BT Telecomunicaciones S.A. que es privada y confidencial, siendo para el uso exclusivo de la persona(s) o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] Gracias
Re: (RADIATOR) RV: DBD Error
Hello Enrique - We have not seen this problem before. It is probably something to do with the DBD-Oracle module. Have you tried different versions? regards Hugh At 17:00 +0200 01/7/10, [EMAIL PROTECTED] wrote: > > Hello, >> >> First time I send a access-request to my radiator server after restarting, >> I can see in my console this error: >> >> DBD::Oracle::db do failed: ORA-12571: TNS:packet writer failure (DBD: >> oopen error) at Radius/SqlDb.pm line 247. >> >> These are the messages that appears in the log file: >> >> Tue Jul 10 16:33:29 2001: DEBUG: OracleDatabase Deleting session for >> 935200550, 10.10.2.3, 1234 >> Tue Jul 10 16:33:29 2001: DEBUG: do query is: delete from RADONLINE where >> NASIDENTIFIER='10.10.2.3' and NASPORT=01234 >> >> Tue Jul 10 16:33:29 2001: ERR: do failed for 'delete from RADONLINE where >> NASIDENTIFIER='10.10.2.3' and NASPORT=01234': ORA-12571: TNS:packet writer >> failure (DBD: oopen error) >> Tue Jul 10 16:33:29 2001: DEBUG: Handling with Radius::AuthSQL >> Tue Jul 10 16:33:29 2001: DEBUG: Handling with Radius::AuthSQL >> >> When I sent more requests, this error does not appear. >> >> Does anyone know why it is happening? Is there a way to avoid this error? >> >> Thanks and regards, >> >> Enrique Carnicero Requena >> BT Telecomunicaciones, S.A. >> C/Isabel Colbrand, 8 >> 28050 - Madrid >> Teléfono: (+34) 91 270 61 88 >> Fax: (+34) 91 270 63 10 >> >** >Noticia legal >Este mensaje electrónico contiene información de BT Telecomunicaciones S.A. >que es privada y confidencial, siendo para el uso exclusivo de la persona >(s) o entidades arriba mencionadas. Si usted no es el destinatario señalado, >le informamos que cualquier divulgación, copia, distribución o uso de los >contenidos está prohibida. Si usted ha recibido este mensaje por error, por >favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] >Gracias. >=== >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. -- NB: I am travelling this week, so there may be delays in our correspondence. 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.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) Using Radiator forWholesaleDialupandSessionDatabase
Hello Tom - If you are using different CalledStationId's, then you can use a RewriteUsername to add the realm and use the special characters %n and %u to store both forms of the username in the session database (you will have to add a field for the rewritten one). Then you can use custom queries in the session database to use the correct one for checking simultaneous use, as well as writing both forms. hth Hugh At 13:53 -0400 01/7/11, Tom Daly wrote: >The DNIS defines who the call belongs to. Each wholesaler is given each a >unique DNIS. > >--Tom > >- Original Message - >From: "Hugh Irvine" <[EMAIL PROTECTED]> >To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Sent: Wednesday, July 11, 2001 2:56 AM >Subject: Re: (RADIATOR) Using Radiator for WholesaleDialupandSessionDatabase > > >> >> Hello Tom - >> >> My point is, how are you going to decide how to apply a >> RewriteUsername if you don't know who the customer belongs to? >> >> regards >> >> Hugh >> >> >> At 12:31 -0400 01/7/9, Tom Daly wrote: >> >I would say that's the problem. Since I enforce a default simultaneous >use >> >of 1 caller, if identical usernames are trying to login from two >different >> >wholesalers, one will be rejected, therefore, I would like to be able to >add >> >a realm name before the username goes into the Session DB. >> > >> >--Tom >> > >> >- Original Message - >> >From: "Hugh Irvine" <[EMAIL PROTECTED]> >> >To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >> >Sent: Saturday, July 07, 2001 12:50 AM >> >Subject: Re: (RADIATOR) Using Radiator for Wholesale >> >DialupandSessionDatabase >> > >> > >> >> >> >> Hello Tom - >> >> >> >> How are you going to know which customer is which? >> >> >> >> regards >> >> >> >> Hugh >> >> >> >> >> >> At 12:51 -0400 01/7/6, Tom Daly wrote: >> >> >Hugh, >> >> > >> >> >I would say my problem then is this. I am using CalledStation.pm to >send >> >> >users to radius proxy which does not use a realm, so users will >dialup >> >with >> >> >'username'. Now, our ISP does not require users to have a realm name >> >either, >> >> >so they also dialup with 'username'. In the case of two identical >> >usernames >> >> >between ISPs, one user will not be authenticated. Is there a way I >can >> >add a >> >> >realm name to the CalledStation.pm users for the sake of the session >> >> >database, however, still send the proxy server just 'username'. I am >> >> >guessing this will need to be done with some sort of hook. >> >> > >> >> >--Tom >> >> > >> >> >- Original Message - >> >> >From: "Hugh Irvine" <[EMAIL PROTECTED]> >> >> >To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >> >> >Sent: Friday, July 06, 2001 12:21 PM >> >> >Subject: Re: (RADIATOR) Using Radiator for Wholesale Dialup >> >> >andSessionDatabase >> >> > >> >> > >> >> >> >> >> >> Hi Tom - >> >> >> >> >> >> By default Radiator uses the username string as received from the >> >> >> NAS, as that is what it needs if it is to query the NAS directly >to >> >> >> verify connections. >> >> >> >> >> >> regards >> >> >> >> >> >> Hugh >> >> >> >> >> >> >> >> >> At 12:29 -0400 01/7/6, Tom Daly wrote: >> >> >> >Hi, >> >> >> > >> >> >> >By default, what entry does Radiator to put into the Session >> >Database? >> >> >From >> >> >> >what I can see, it seems that it copies the as entered >by >> >the >> >> >> >user, before any rewrite username, or other functions are used. >> >> >> > >> >> >> >Tom >> >> >> > >> >> >> >- Original Message - >> >> >> >From: "Hugh Irvine" <[EMAIL PROTECTED]> >> >> >> >To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >> >> >> >Sent: Friday, July 06, 2001 5:44 AM >> >> >> >Subject: Re: (RADIATOR) Using Radiator for Wholesale Dialup and >> >> >> >SessionDatabase >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Hello Tom - >> >> >> >> >> >> >> >> At 12:17 -0400 01/7/5, Tom Daly wrote: >> >> >> >> >Hello, > > >> >> >> >We are currently using Radiator and MySQL for a SessionDB. As >a >> >> >wholesale >> >> >> >> >provider, we have two ways for our wholesalers to access >> >accounts. >> >> >> >> > >> >> >> >> >1. Per Port - An ISP is assigned a unique DNIS to which all >> >radius >> >> >> >requested >> >> >> >> >are directed at thier radius server by proxy. We do this by >the >> >> >following >> >> >> >> >method. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > Host xxx.xxx.xxx.xxx >> >> >> >> > Secret VeryVerySecret >> >> >> >> > AuthPort 1645 >> >> >> >> > AcctPort 1646 >> >> >> >> > Retries 5 >> >> >> >> > RetryTimeout 15 >> >> >> >> > >> >> >> >> > >> >> >> >> >This method seems to be slow, as we h
Re: (RADIATOR) changing the realm.
Hello Griff -
As has been mentioned elsewhere, Realm is not an attribute, rather it
is the suffix on a username after the "@" sign.
hth
Hugh
At 9:50 -0700 01/7/11, Griff Hamlin wrote:
>Hello all,
>
>I am trying to take the username (including realm or not) that comes in
>from the packet, strip the realm and then put on a new one based on the
>radius client that is providing the packet. I have the following in a
>client block:
>
>
>RewriteUsername s/^([^@]+).*/$1/
>Secret mysecret
>PreHandlerHook sub { ${$_[0]}->change_attr('Realm','home'); \
> my $request = ${$_[0]}; \
> my $attrref = $request->{Attributes}; \
> my @attr = @$attrref; \
> foreach (@attr) { \
>my @attr2 = @$_; \
>my $attr3; \
>foreach $attr3 (@attr2) { \
> print "attribute is '$attr3'\n"; \
>}\
> }\
> }
>
>
>Mostly, what happens is I try and use the 'change_attr' method to change
>the realm from whatever it was to 'home'. However, when I tried then
>using a block, it never noticed the new realm,
>and continued with the old realm as per the following log file segment:
>
>attribute is 'User-Name'
>attribute is 'hamlin'
>attribute is 'Service-Type'
>attribute is 'Framed-User'
>attribute is 'NAS-IP-Address'
>attribute is '203.63.154.1'
>attribute is 'NAS-Port'
>attribute is '1234'
>attribute is 'Called-Station-Id'
>attribute is '123456789'
>attribute is 'Calling-Station-Id'
>attribute is '987654321'
>attribute is 'NAS-Port-Type'
>attribute is 'Async'
>attribute is 'Framed-IP-Address'
>attribute is '255.255.255.254'
>attribute is 'User-Password'
>attribute is 'ϸfß5pö¼8 Ø}x'
>attribute is 'Realm'
>attribute is 'home'
>Wed Jul 11 10:45:34 2001: DEBUG: Packet dump:
>*** Received from 65.13.83.72 port 1027
>Code: Access-Request
>Identifier: 124
>Authentic: 1234567890123456
>Attributes:
> User-Name = "[EMAIL PROTECTED]"
> Service-Type = Framed-User
> NAS-IP-Address = 203.63.154.1
> NAS-Port = 1234
> Called-Station-Id = "123456789"
> Calling-Station-Id = "987654321"
> NAS-Port-Type = Async
> Framed-IP-Address = 255.255.255.254
> User-Password =
>"<207><184>f<154><223>5p<246><188>8<9><160><216>}x<153>"
>Wed Jul 11 10:45:34 2001: DEBUG: Rewrote user name to hamlin
>Wed Jul 11 10:45:34 2001: DEBUG: Check if Handler Realm = home should be
>used to handle this request
>Wed Jul 11 10:45:34 2001: DEBUG: Check if Handler should be used to
>handle this request
>Wed Jul 11 10:45:34 2001: DEBUG: Handling request with Handler ''
>Wed Jul 11 10:45:34 2001: DEBUG: Deleting session for
>[EMAIL PROTECTED], 203.63.154.1, 1234
>
>As you can see, when printing out attributes, it shows the Realm to be
>'home', and later when doing the packet dump, the username is
>[EMAIL PROTECTED] as it was sent from the radius client. Maybe this is
>not possible, which would be OK I have other ideas to work around it.
>But now I'm curious.
>
>Griff Hamlin,
>
>
>===
>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.
--
NB: I am travelling this week, so there may be delays in our correspondence.
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.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) LDAP_NO_SUCH_OBJECT. Disconnecting with Radiatorand Netscape LDAP server
Title: Re: (RADIATOR) LDAP_NO_SUCH_OBJECT. Disconnecting
with
Hello Sajida -
The first thing to do is upgrade to Radiator 2.18.2.
Then I will need to see a copy of your configuration file (no
secrets) together with the trace 4 debug.
From what you show below, it looks like the object you are
looking for is not in the LDAP database.
hth
Hugh
At 12:12 +0500 01/7/10, sajida kalsoom wrote:
Hi
users!
Can
any one please help me...
I am
using Netscape LDAP server 3.1 on windows 2000 server and Radiator
2.15 on solaris sparc. My problem is that whenevrer I try to connect
and use LDAP server i get the following error when running this
:
#
./radpwtst -user sajida -password skalsoom
error is
...
##
Mon
Jul 9 19:07:35 2001: INFO: Server started: Radiator 2.15
Mon Jul 9 19:08:29 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32836
Code: Access-Request
Identifier: 73
Authentic: 1234567890123456
Attributes:
User-Name =
"sajida"
Service-Type =
Framed-User
NAS-IP-Address =
203.63.154.1
NAS-Port = 1234
NAS-Port-Type = Async
User-Password =
"<138><224>><193><220>3k<155><188>8<9><160><216>}x<153>"
Mon
Jul 9 19:08:29 2001: DEBUG: Handling request with Handler
'Realm=DEFAULT'
Mon Jul 9 19:08:29 2001: DEBUG: Deleting session for
sajida, 203.63.154.1, 1234
Mon Jul 9 19:08:29 2001: DEBUG: Handling with
Radius::AuthLDAP2
Mon Jul 9 19:08:29 2001: DEBUG: Connecting to 192.168.0.122,
port 389
Net::LDAP=HASH(0x531028) sending:
30 3B 02 01
01 60 36 02 01 02 04 22 63 6E 3D 44 0;...`6"cn=D
69 72 65 63 74 6F 72 79 20 4D 61 6E 61 67 65 72 irectory Manager
2C 20 6F 3D 41 69 72 69 75 73 2E 63 6F 6D 80 0D , o=Airius.com..
73 61 6A 69 64 61 6B 61 6C 73 6F 6F 6D __ __ __
sajidakalsoom
30 59: SEQUENCE {
0002 02 1: INTEGER = 1
0005 60 54: [APPLICATION 0] {
0007 02 1: INTEGER = 2
000A 04 34: STRING =
'cn=Directory Manager, o=Airius.com'
002E 80 13: [CONTEXT 0]
0030
: 73 61 6A 69 64 61 6B 61 6C 73
6F 6F 6D __ __ __ sajidakalsoom
003D : }
003D : }
Net::LDAP=HASH(0x531028) received:
30 18 02 01
01 61 13 0A 01 20 04 0C 6F 3D 61 69 0a... ..o=ai
72 69 75 73 2E 63 6F 6D 04 00 __ __ __ __ __ __
rius.com..
30 24: SEQUENCE {
0002 02 1: INTEGER = 1
0005 61 19: [APPLICATION 1] {
0007 0A 1: ENUM = 32
000A 04 12: STRING =
'o=airius.com'
0018 04 0: STRING = ''
001A : }
001A : }
Mon Jul 9 19:08:29 2001: ERR: Could not bind connection with
cn=Directory Manager, o=Airius.com, sajidakalsoom, error:
LDAP_NO_SUCH_OBJECT. Disconnecting
##
--
NB:
I am travelling this week, so there may be delays in our
correspondence.
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.
Re: (RADIATOR) AuthBy Radius, limiting Calling ID stations
Hello Lloyd - I would suggest that you use the AuthBy PORTLIMITCHECK clause before proxying the request. Note that you will need to use a SessionDatabase SQL to be able to use AuthBy PORTLIMITCHECK. hth Hugh At 14:56 +0800 01/7/11, lloyd wrote: >hi there, >this is what we have right nowwe have this radius that does >authentication...our radius also does proxying to other radius by AuthBy >Radius clause...our problem right now is how do we limit the users say >user01@realm1 from dialling at Calling-Station-Id, say 1234? > >the complication: if our radius finds out that the user has realm = >realm1, it proxys it to another radius server but before our radius >server proxys that particular user, we need to find out if that user is >dialling the correct Calling-Station-Idso the question is how do we >proxy to another radius together with limiting that particular user from >dialling to a set of numbers.. > >does this work? or do you have any suggestions in mind? > >Client-Id=/202.202.202.202/> > > Host > Secret *** > AuthPort > AcctPort > > > >p.s. >follow-up: how do we bind to NO PORT...i mean how do we reject >completely a usersay for >exampleNOT BINDING TO AN AUTHPORT OR NOT BINDING TO AN ACCTPORT? > > >that's all i guess >thank you >hope you can reply soon > > >Lloyd Brian V. Dagoc >Consulting Engineer >InterDotNet Philipines Incorporated > >=== >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. -- NB: I am travelling this week, so there may be delays in our correspondence. 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.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) IMPORTANT - MaxSessions problem in Radiator 2.18
Hello Dmitry - You should just upgrade to Radiator 2.18.2. regards Hugh At 17:43 +0200 01/7/11, Dmitry Kopylov wrote: >Hello, > >We run ver. 2.18 and I think we have mentioned problem with the MaxSession >but I can't find any patches in the patch area. Can I count on help? > >regards, >Dmitry Kopylov > >Network Architect ISP/DSL >BBned >Saturnusstraat 40-44 >2132 HB Hoofdorp >Phone: +31 23 5659953 >Fax: +31 23 5633356 >Mobile: +31 62 7047960 > > >-Original Message- >From: Hugh Irvine [mailto:[EMAIL PROTECTED]] >Sent: Thursday, March 22, 2001 3:42 AM >To: Frederic Gargula >Cc: [EMAIL PROTECTED] >Subject: (RADIATOR) IMPORTANT - MaxSessions problem in Radiator 2.18 > > > >Salut Fred, Salut Tout-le-monde - > >There is a slight error in Radiator 2.18 when using MaxSessions in a Realm >or >Handler. There is a patched version of Handler.pm in the patches area. > >Merci a Fred de l'avoir trouve! > >A+ > >Hugues > > >-- >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. > >=== >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.open.com.au/archives/radiator/ >Announcements on [EMAIL PROTECTED] >To unsubscribe, email '[EMAIL PROTECTED]' with >'unsubscribe radiator' in the body of the message. -- NB: I am travelling this week, so there may be delays in our correspondence. 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.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) changing the realm.
I was confused about the same thing at one point.
"Realm" to Radiator is not an attribute but rather the portion of the
username following the "@".
To work around this, we have a hook somewhat similar to yours which:
1) Strips the @realm.com off the username
2) Creates a new custom attribute, NC-Realm = realm.com
3) Then, if you need to Handle in special ways, you use .
Make sense?
Dave
> -Original Message-
> From: Griff Hamlin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 11, 2001 12:50 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) changing the realm.
>
>
> Hello all,
>
> I am trying to take the username (including realm or not)
> that comes in from the packet, strip the realm and then put
> on a new one based on the radius client that is providing the
> packet. I have the following in a client block:
>
>
>RewriteUsername s/^([^@]+).*/$1/
>Secret mysecret
>PreHandlerHook sub { ${$_[0]}->change_attr('Realm','home'); \
> my $request = ${$_[0]}; \
> my $attrref = $request->{Attributes}; \
> my @attr = @$attrref; \
> foreach (@attr) { \
>my @attr2 = @$_; \
>my $attr3; \
>foreach $attr3 (@attr2) { \
> print "attribute is '$attr3'\n"; \
>}\
> }\
> }
>
>
> Mostly, what happens is I try and use the 'change_attr'
> method to change the realm from whatever it was to 'home'.
> However, when I tried then using a
> block, it never noticed the new realm, and continued with the
> old realm as per the following log file segment:
>
> attribute is 'User-Name'
> attribute is 'hamlin'
> attribute is 'Service-Type'
> attribute is 'Framed-User'
> attribute is 'NAS-IP-Address'
> attribute is '203.63.154.1'
> attribute is 'NAS-Port'
> attribute is '1234'
> attribute is 'Called-Station-Id'
> attribute is '123456789'
> attribute is 'Calling-Station-Id'
> attribute is '987654321'
> attribute is 'NAS-Port-Type'
> attribute is 'Async'
> attribute is 'Framed-IP-Address'
> attribute is '255.255.255.254'
> attribute is 'User-Password'
> attribute is 'ϸfß5pö¼8 Ø}x'
> attribute is 'Realm'
> attribute is 'home'
> Wed Jul 11 10:45:34 2001: DEBUG: Packet dump:
> *** Received from 65.13.83.72 port 1027
> Code: Access-Request
> Identifier: 124
> Authentic: 1234567890123456
> Attributes:
> User-Name = "[EMAIL PROTECTED]"
> Service-Type = Framed-User
> NAS-IP-Address = 203.63.154.1
> NAS-Port = 1234
> Called-Station-Id = "123456789"
> Calling-Station-Id = "987654321"
> NAS-Port-Type = Async
> Framed-IP-Address = 255.255.255.254
> User-Password =
> "<207><184>f<154><223>5p<246><188>8<9><160><216>}x<153>"
> Wed Jul 11 10:45:34 2001: DEBUG: Rewrote user name to hamlin
> Wed Jul 11 10:45:34 2001: DEBUG: Check if Handler Realm =
> home should be used to handle this request Wed Jul 11
> 10:45:34 2001: DEBUG: Check if Handler should be used to
> handle this request Wed Jul 11 10:45:34 2001: DEBUG: Handling
> request with Handler '' Wed Jul 11 10:45:34 2001: DEBUG:
> Deleting session for [EMAIL PROTECTED], 203.63.154.1, 1234
>
> As you can see, when printing out attributes, it shows the
> Realm to be 'home', and later when doing the packet dump, the
> username is [EMAIL PROTECTED] as it was sent from the radius
> client. Maybe this is not possible, which would be OK I have
> other ideas to work around it. But now I'm curious.
>
> Griff Hamlin,
>
>
> ===
> 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.
(RADIATOR) changing the realm.
Hello all,
I am trying to take the username (including realm or not) that comes in
from the packet, strip the realm and then put on a new one based on the
radius client that is providing the packet. I have the following in a
client block:
RewriteUsername s/^([^@]+).*/$1/
Secret mysecret
PreHandlerHook sub { ${$_[0]}->change_attr('Realm','home'); \
my $request = ${$_[0]}; \
my $attrref = $request->{Attributes}; \
my @attr = @$attrref; \
foreach (@attr) { \
my @attr2 = @$_; \
my $attr3; \
foreach $attr3 (@attr2) { \
print "attribute is '$attr3'\n"; \
}\
}\
}
Mostly, what happens is I try and use the 'change_attr' method to change
the realm from whatever it was to 'home'. However, when I tried then
using a block, it never noticed the new realm,
and continued with the old realm as per the following log file segment:
attribute is 'User-Name'
attribute is 'hamlin'
attribute is 'Service-Type'
attribute is 'Framed-User'
attribute is 'NAS-IP-Address'
attribute is '203.63.154.1'
attribute is 'NAS-Port'
attribute is '1234'
attribute is 'Called-Station-Id'
attribute is '123456789'
attribute is 'Calling-Station-Id'
attribute is '987654321'
attribute is 'NAS-Port-Type'
attribute is 'Async'
attribute is 'Framed-IP-Address'
attribute is '255.255.255.254'
attribute is 'User-Password'
attribute is 'ϸfß5pö¼8 Ø}x'
attribute is 'Realm'
attribute is 'home'
Wed Jul 11 10:45:34 2001: DEBUG: Packet dump:
*** Received from 65.13.83.72 port 1027
Code: Access-Request
Identifier: 124
Authentic: 1234567890123456
Attributes:
User-Name = "[EMAIL PROTECTED]"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = "123456789"
Calling-Station-Id = "987654321"
NAS-Port-Type = Async
Framed-IP-Address = 255.255.255.254
User-Password =
"<207><184>f<154><223>5p<246><188>8<9><160><216>}x<153>"
Wed Jul 11 10:45:34 2001: DEBUG: Rewrote user name to hamlin
Wed Jul 11 10:45:34 2001: DEBUG: Check if Handler Realm = home should be
used to handle this request
Wed Jul 11 10:45:34 2001: DEBUG: Check if Handler should be used to
handle this request
Wed Jul 11 10:45:34 2001: DEBUG: Handling request with Handler ''
Wed Jul 11 10:45:34 2001: DEBUG: Deleting session for
[EMAIL PROTECTED], 203.63.154.1, 1234
As you can see, when printing out attributes, it shows the Realm to be
'home', and later when doing the packet dump, the username is
[EMAIL PROTECTED] as it was sent from the radius client. Maybe this is
not possible, which would be OK I have other ideas to work around it.
But now I'm curious.
Griff Hamlin,
===
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) Using Radiator for WholesaleDialupandSessionDatabase
The DNIS defines who the call belongs to. Each wholesaler is given each a unique DNIS. --Tom - Original Message - From: "Hugh Irvine" <[EMAIL PROTECTED]> To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, July 11, 2001 2:56 AM Subject: Re: (RADIATOR) Using Radiator for WholesaleDialupandSessionDatabase > > Hello Tom - > > My point is, how are you going to decide how to apply a > RewriteUsername if you don't know who the customer belongs to? > > regards > > Hugh > > > At 12:31 -0400 01/7/9, Tom Daly wrote: > >I would say that's the problem. Since I enforce a default simultaneous use > >of 1 caller, if identical usernames are trying to login from two different > >wholesalers, one will be rejected, therefore, I would like to be able to add > >a realm name before the username goes into the Session DB. > > > >--Tom > > > >- Original Message - > >From: "Hugh Irvine" <[EMAIL PROTECTED]> > >To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > >Sent: Saturday, July 07, 2001 12:50 AM > >Subject: Re: (RADIATOR) Using Radiator for Wholesale > >DialupandSessionDatabase > > > > > >> > >> Hello Tom - > >> > >> How are you going to know which customer is which? > >> > >> regards > >> > >> Hugh > >> > >> > >> At 12:51 -0400 01/7/6, Tom Daly wrote: > >> >Hugh, > >> > > >> >I would say my problem then is this. I am using CalledStation.pm to send > >> >users to radius proxy which does not use a realm, so users will dialup > >with > >> >'username'. Now, our ISP does not require users to have a realm name > >either, > >> >so they also dialup with 'username'. In the case of two identical > >usernames > >> >between ISPs, one user will not be authenticated. Is there a way I can > >add a > >> >realm name to the CalledStation.pm users for the sake of the session > >> >database, however, still send the proxy server just 'username'. I am > >> >guessing this will need to be done with some sort of hook. > >> > > >> >--Tom > >> > > >> >- Original Message - > >> >From: "Hugh Irvine" <[EMAIL PROTECTED]> > >> >To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > >> >Sent: Friday, July 06, 2001 12:21 PM > >> >Subject: Re: (RADIATOR) Using Radiator for Wholesale Dialup > >> >andSessionDatabase > >> > > >> > > >> >> > >> >> Hi Tom - > >> >> > >> >> By default Radiator uses the username string as received from the > >> >> NAS, as that is what it needs if it is to query the NAS directly to > >> >> verify connections. > >> >> > >> >> regards > >> >> > >> >> Hugh > >> >> > >> >> > >> >> At 12:29 -0400 01/7/6, Tom Daly wrote: > >> >> >Hi, > >> >> > > >> >> >By default, what entry does Radiator to put into the Session > >Database? > >> >From > >> >> >what I can see, it seems that it copies the as entered by > >the > >> >> >user, before any rewrite username, or other functions are used. > >> >> > > >> >> >Tom > >> >> > > >> >> >- Original Message - > >> >> >From: "Hugh Irvine" <[EMAIL PROTECTED]> > >> >> >To: "Tom Daly" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > >> >> >Sent: Friday, July 06, 2001 5:44 AM > >> >> >Subject: Re: (RADIATOR) Using Radiator for Wholesale Dialup and > >> >> >SessionDatabase > >> >> > > >> >> > > >> >> >> > >> >> >> Hello Tom - > >> >> >> > >> >> >> At 12:17 -0400 01/7/5, Tom Daly wrote: > >> >> >> >Hello, > >> >> >> >We are currently using Radiator and MySQL for a SessionDB. As a > >> >wholesale > >> >> >> >provider, we have two ways for our wholesalers to access > >accounts. > >> >> >> > > >> >> >> >1. Per Port - An ISP is assigned a unique DNIS to which all > >radius > >> >> >requested > >> >> >> >are directed at thier radius server by proxy. We do this by the > >> >following > >> >> >> >method. > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > Host xxx.xxx.xxx.xxx > >> >> >> > Secret VeryVerySecret > >> >> >> > AuthPort 1645 > >> >> >> > AcctPort 1646 > >> >> >> > Retries 5 > >> >> >> > RetryTimeout 15 > >> >> >> > > >> >> >> > > >> >> >> >This method seems to be slow, as we have to search through a few > >> >hundred > >> >> >> >DNISs for the same provider, if they have multiple DNISs. So I am > >> >looking > >> >> >> >for a way to use one statement that will search each providers > >list > >> >of > >> >> >> >DNISs. Also, when a customer dials in, thier username is just > >> >username. > >> >> >It > >> >> >> >there a way to make the session database show > >[EMAIL PROTECTED], > >> >but > >> >> >> >still pass username to the proxy radius server? > >> >> >> > >> >> >> > >> >> >> If you are using the "CalledStationId.pm" file from the goodies > >> >> >> section of the distribution, there is almost no overhead, as the > >> >> >> number that is specified in the
RE: (RADIATOR) IMPORTANT - MaxSessions problem in Radiator 2.18
Hello, We run ver. 2.18 and I think we have mentioned problem with the MaxSession but I can't find any patches in the patch area. Can I count on help? regards, Dmitry Kopylov Network Architect ISP/DSL BBned Saturnusstraat 40-44 2132 HB Hoofdorp Phone: +31 23 5659953 Fax: +31 23 5633356 Mobile: +31 62 7047960 -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 3:42 AM To: Frederic Gargula Cc: [EMAIL PROTECTED] Subject: (RADIATOR) IMPORTANT - MaxSessions problem in Radiator 2.18 Salut Fred, Salut Tout-le-monde - There is a slight error in Radiator 2.18 when using MaxSessions in a Realm or Handler. There is a patched version of Handler.pm in the patches area. Merci a Fred de l'avoir trouve! A+ Hugues -- 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. === 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.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) accept all auth-req
Hi, you can include a group in your Realm like this: AuthBy GROUP_Identifier . . and your group could be compose of two AuthBy authenticators: AuthByPolicy ContinueUntilAccept Identifier GROUP_Identifier AuthBy RADMIN_Identifier AuthBy TEST_Identifier So in that way I think you first will authenticate via RADMIN, and in case of failure, AuthBy TEST will always accept your authentication requests. Test it and tell me if it works. regards, jules -Mensaje original- De: chairarth [mailto:[EMAIL PROTECTED]] Enviado el: lunes 9 de julio de 2001 10:38 Para: radiator Asunto: (RADIATOR) accept all auth-req Hi, In case of Authen by Radmin , how can I config Radiator to accept all authen-requests whenever the SQL Host down. Regards, Chairath ** Noticia legal Este mensaje electrónico contiene información de BT Telecomunicaciones S.A. que es privada y confidencial, siendo para el uso exclusivo de la persona(s) o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] Gracias === 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) SQL Server 2000
Yes, it does. Try the driver at www.merant.com (This driver is not free, but its not a proxy driver like most others either) -Original Message- From: Daud Yusof [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 11, 2001 7:01 AM To: Radiator Subject: (RADIATOR) SQL Server 2000 Hi there, I know that radiator works with MSSQL Server 7 but what about SQL Server 2000 ? Has anybody tried this config ? No reason it should not, right ? Thanks === 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.
(RADIATOR) SQL Server 2000
Hi there, I know that radiator works with MSSQL Server 7 but what about SQL Server 2000 ? Has anybody tried this config ? No reason it should not, right ? Thanks === 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) AuthBy Radius, limiting Calling ID stations
hi there, this is what we have right nowwe have this radius that does authentication...our radius also does proxying to other radius by AuthBy Radius clause...our problem right now is how do we limit the users say user01@realm1 from dialling at Calling-Station-Id, say 1234? the complication: if our radius finds out that the user has realm = realm1, it proxys it to another radius server but before our radius server proxys that particular user, we need to find out if that user is dialling the correct Calling-Station-Idso the question is how do we proxy to another radius together with limiting that particular user from dialling to a set of numbers.. does this work? or do you have any suggestions in mind? Host Secret *** AuthPort AcctPort p.s. follow-up: how do we bind to NO PORT...i mean how do we reject completely a usersay for exampleNOT BINDING TO AN AUTHPORT OR NOT BINDING TO AN ACCTPORT? that's all i guess thank you hope you can reply soon Lloyd Brian V. Dagoc Consulting Engineer InterDotNet Philipines Incorporated === 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) Radiator with SQL Server 2000
--- Forwarded mail from [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Tue, 10 Jul 2001 23:56:40 -0500 To: [EMAIL PROTECTED] Subject: BOUNCE [EMAIL PROTECTED]:Non-member submission from ["Daud Yusof" <[EMAIL PROTECTED]>] >From [EMAIL PROTECTED] Tue Jul 10 23:56:40 2001 Received: from mail5.nettwerk.com.sg ([203.126.68.61]) by server1.open.com.au (8.11.0/8.11.0) with ESMTP id f6B4uXD04955 for <[EMAIL PROTECTED]>; Tue, 10 Jul 2001 23:56:38 -0500 Received: from daudy [202.79.95.12] by mail5.nettwerk.com.sg [203.126.68.60] with SMTP (MDaemon.v3.5.0.R) for <[EMAIL PROTECTED]>; Wed, 11 Jul 2001 14:48:48 +0800 From: "Daud Yusof" <[EMAIL PROTECTED]> To: "Radiator" <[EMAIL PROTECTED]> Subject: Radiator with SQL Server 2000 Date: Wed, 11 Jul 2001 14:48:51 +0800 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 202.79.95.12 X-Return-Path: [EMAIL PROTECTED] X-MDaemon-Deliver-To: [EMAIL PROTECTED] Hi there, I know that radiator works with MSSQL Server 7 but what about SQL Server 2000 ? Has anybody tried this config ? No reason it should not, right ? Thanks ---End of forwarded mail from [EMAIL PROTECTED] -- 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 etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === 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.
