Re: (RADIATOR) Bug?
Hello Toomas,
On Wed, 18 Dec 2002 18:41, Toomas Kärner wrote:
Hi all,
Sorry, my bad
I looked at the code, understanded it and looked at the manual again and
realized that NoDefault is affective in case of REJECT and NOT only in case
on Not found. That started my little snowball. Only real idea that grew out
of this is that maybe $defaultNumber should have a limit. With my loop I
created 52000 request's to SQL and I can't think a reason why someone
should need so many defaults and would allow them in so big cost of load. I
think 512 should by way enough.
OK, we have added a limit of 512 DEFAULT users for the next release.
Thanks for the suggestion.
Cheers.
Rgds and appologies.
Toomas Kärner
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Toomas Kärner [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, December 13, 2002 11:50 PM
Subject: Re: (RADIATOR) Bug?
Hello Toomas -
The fundamental issue is the architecture of Radiator itself and
specifically the AuthBy clauses, all of which fundamentally implement a
find_user routine which is why you see the problem that you do.
You are correct that what I show below is a workaround, ie. the first
AuthBy uses a couple of DEFAULT entries so that find_user works, then
passes off the request using the Auth-Type construct to an AuthBy
clause in which you can do anything you like.
The extra processing overhead is minimal, as the AuthBy FILE will cache
the DEFAULT lines in memory and will simply do a couple of memory
lookups.
I encourage you to have a look at the code in Radius/AuthGeneric.pm
and Radius/AuthSQL.pm to see what goes on.
I have also copied this mail to Mike for his additional comments.
regards
Hugh
On Friday, Dec 13, 2002, at 22:26 Australia/Melbourne, Toomas Kärner
wrote:
Hi,
So, AuthBy's like:
AuthBy SQL
Identifier AuthBlacklistCheck
DBSourcedbi:mysql:
DBUsername
DBAuth
AuthSelect select MACADDRESS, REPLYMESSAGE from macblacklist where \
MACADDRESS like '%{Calling-Station-Id}' and \
ACTIVE = 'Yes'
AuthColumnDef 0, Service-Type,check
AuthColumnDef 1, Reply-Message,reply
NoDefault
AcceptIfMissing
/AuthBy
and
AuthBy SQL
Identifier AuthUser
DBSource dbi:mysql:
DBUsername
DBAuth
AuthSelect select ACTIVE, WNACCESS, CHECKATTR, PASSWORD,\
REPLYATTR \
from xx where USERNAME ='%n'
AuthColumnDef 0, ETC-Admin-Active, check
AuthColumnDef 1, ETC-Admin-Wireless, check
AuthColumnDef 2, GENERIC, check
AuthColumnDef 3, User-Password, check
AuthColumnDef 4, GENERIC, reply
DefaultSimultaneousUse 1
NoDefault
RejectEmptyPassword
AccountingTable log
AcctColumnDef DATE,Timestamp ,formatted-date,'%Y-%m-%d'
.
.
.
/AuthBy
and realm like
Realm admin
RewriteUsername s/^([^@]+).*/$1/
AuthByPolicy ContinueUntilReject
AuthBy AuthBlacklistCheck
AuthBy AuthUser
/Realm admin
is impossible because AuthBlacklistCheck has nothing to do with
usernames
and that freaks it out to go to loop with DEFAULT? I think that this
is more
than configuration issue and configuration that you gave me is more
like a
workaround that probably takes more load. If this is true that if no
such
thing as username is received from sql results in a new query with
default
username then it is impossible to use radiator for authentication of
layer
2. If you are confused what I mean by Layer 2 authentication, this is
checking layer 2 information for given request and if that succeeds
then go
forward with username authentication.
Also from the Archive: 17. oct. 2002 to [EMAIL PROTECTED] you said:
{
The reason for doing it this way is because the AuthBy processing is
looking for a user, which the AuthBy SQL clause is not doing.
}
I don't want to do anything with user in that AuthBy, I just want to
verify
2L information. Is that a limitation in Radiator?
Rgds.
Toomas
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Toomas Kärner [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, December 13, 2002 12:59 AM
Subject: Re: (RADIATOR) Bug?
Hello Toomas -
This is not a bug really - it is more a configuration issue.
The problem that you show below is due to the fact that the AuthBy is
looking for the username, and you are overriding it to look for
something else. This leads to the AuthBy continuing to look for
DEFAULT... .
The
RE: (RADIATOR) Bug?
Unfortunatley, we make extensive use of default users as we do not care what username
or password the enduser enters, as long as he connects to our server. We are a mobile
cellular operator and allow users onto our Ericsson GGSN on the Internet APN...payment
is per kilobyte transferred and we have the users MSISDN to bill.
So Please DO NOT put a limit on the number of DEFAULT users, as this will severly
affect our operations!
thanks
Surajh Surjoo
Systems Engineer - Data
Mobile: 0832129829
Mobile Fax: 083 8 2129829
Office Fax: 011 3018811
Office Tel: 011 3016000
[EMAIL PROTECTED]
Imagination is more important than Knowledge - Albert Einstein
-Original Message-
From: Mike McCauley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 18 December 2002 10:32 AM
To: Toomas Kärner; Hugh Irvine
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Bug?
Hello Toomas,
On Wed, 18 Dec 2002 18:41, Toomas Kärner wrote:
Hi all,
Sorry, my bad
I looked at the code, understanded it and looked at the manual again and
realized that NoDefault is affective in case of REJECT and NOT only in case
on Not found. That started my little snowball. Only real idea that grew out
of this is that maybe $defaultNumber should have a limit. With my loop I
created 52000 request's to SQL and I can't think a reason why someone
should need so many defaults and would allow them in so big cost of load. I
think 512 should by way enough.
OK, we have added a limit of 512 DEFAULT users for the next release.
Thanks for the suggestion.
Cheers.
Rgds and appologies.
Toomas Kärner
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Toomas Kärner [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, December 13, 2002 11:50 PM
Subject: Re: (RADIATOR) Bug?
Hello Toomas -
The fundamental issue is the architecture of Radiator itself and
specifically the AuthBy clauses, all of which fundamentally implement a
find_user routine which is why you see the problem that you do.
You are correct that what I show below is a workaround, ie. the first
AuthBy uses a couple of DEFAULT entries so that find_user works, then
passes off the request using the Auth-Type construct to an AuthBy
clause in which you can do anything you like.
The extra processing overhead is minimal, as the AuthBy FILE will cache
the DEFAULT lines in memory and will simply do a couple of memory
lookups.
I encourage you to have a look at the code in Radius/AuthGeneric.pm
and Radius/AuthSQL.pm to see what goes on.
I have also copied this mail to Mike for his additional comments.
regards
Hugh
On Friday, Dec 13, 2002, at 22:26 Australia/Melbourne, Toomas Kärner
wrote:
Hi,
So, AuthBy's like:
AuthBy SQL
Identifier AuthBlacklistCheck
DBSourcedbi:mysql:
DBUsername
DBAuth
AuthSelect select MACADDRESS, REPLYMESSAGE from macblacklist where \
MACADDRESS like '%{Calling-Station-Id}' and \
ACTIVE = 'Yes'
AuthColumnDef 0, Service-Type,check
AuthColumnDef 1, Reply-Message,reply
NoDefault
AcceptIfMissing
/AuthBy
and
AuthBy SQL
Identifier AuthUser
DBSource dbi:mysql:
DBUsername
DBAuth
AuthSelect select ACTIVE, WNACCESS, CHECKATTR, PASSWORD,\
REPLYATTR \
from xx where USERNAME ='%n'
AuthColumnDef 0, ETC-Admin-Active, check
AuthColumnDef 1, ETC-Admin-Wireless, check
AuthColumnDef 2, GENERIC, check
AuthColumnDef 3, User-Password, check
AuthColumnDef 4, GENERIC, reply
DefaultSimultaneousUse 1
NoDefault
RejectEmptyPassword
AccountingTable log
AcctColumnDef DATE,Timestamp ,formatted-date,'%Y-%m-%d'
.
.
.
/AuthBy
and realm like
Realm admin
RewriteUsername s/^([^@]+).*/$1/
AuthByPolicy ContinueUntilReject
AuthBy AuthBlacklistCheck
AuthBy AuthUser
/Realm admin
is impossible because AuthBlacklistCheck has nothing to do with
usernames
and that freaks it out to go to loop with DEFAULT? I think that this
is more
than configuration issue and configuration that you gave me is more
like a
workaround that probably takes more load. If this is true that if no
such
thing as username is received from sql results in a new query with
default
username then it is impossible to use radiator for authentication of
layer
2. If you are confused what I mean by Layer 2 authentication, this is
checking layer 2 information for given request and if that succeeds
then go
forward with username authentication.
Also from the Archive: 17. oct. 2002 to [EMAIL
(RADIATOR) GRIC and HOST clause
Hi, I was just wondering if this would work since I define my Clients in a SQL DB and the NAS clients are going to be the same for all dialup parties. (Your GRIC example in the Ref Manual assumes you have a different client defined for the GRIC customers.) Realm DEFAULT AuthBy RADIUS Host a.b.c.d Secret IgnoreAcctSignature (This isn't included in the Ref Manual as being a valid entry here) /Host /AuthBy /Realm I somehow don't think this will work since it is a client clause and not a radius clause so how do I work around my NAS and IgnoreAcctSignature? If I included it in the SQL table would it make a difference for my regular realms? I read the REF guide on this flag but I am a bit daft and don't understand the implications of it being put in for a NAS that DOESN'T need it. Craig. === 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) Bug?
Hello Surajh,
thanks for your note.
On Wed, 18 Dec 2002 20:15, Surajh Surjoo [ MTN Sandhurst ] wrote:
Unfortunatley, we make extensive use of default users as we do not care
what username or password the enduser enters, as long as he connects to our
server. We are a mobile cellular operator and allow users onto our
Ericsson GGSN on the Internet APN...payment is per kilobyte transferred and
we have the users MSISDN to bill.
So Please DO NOT put a limit on the number of DEFAULT users, as this will
severly affect our operations!
OK, we have instead added a new parameter DefaultLimit that allows you to
impose a limit if you wish, but which defaults to no limit.
OK?
Cheers.
thanks
Surajh Surjoo
Systems Engineer - Data
Mobile: 0832129829
Mobile Fax: 083 8 2129829
Office Fax: 011 3018811
Office Tel: 011 3016000
[EMAIL PROTECTED]
Imagination is more important than Knowledge - Albert Einstein
-Original Message-
From: Mike McCauley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 18 December 2002 10:32 AM
To: Toomas Kärner; Hugh Irvine
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Bug?
Hello Toomas,
On Wed, 18 Dec 2002 18:41, Toomas Kärner wrote:
Hi all,
Sorry, my bad
I looked at the code, understanded it and looked at the manual again and
realized that NoDefault is affective in case of REJECT and NOT only in
case on Not found. That started my little snowball. Only real idea that
grew out of this is that maybe $defaultNumber should have a limit. With
my loop I created 52000 request's to SQL and I can't think a reason why
someone should need so many defaults and would allow them in so big cost
of load. I think 512 should by way enough.
OK, we have added a limit of 512 DEFAULT users for the next release.
Thanks for the suggestion.
Cheers.
Rgds and appologies.
Toomas Kärner
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Toomas Kärner [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, December 13, 2002 11:50 PM
Subject: Re: (RADIATOR) Bug?
Hello Toomas -
The fundamental issue is the architecture of Radiator itself and
specifically the AuthBy clauses, all of which fundamentally implement a
find_user routine which is why you see the problem that you do.
You are correct that what I show below is a workaround, ie. the first
AuthBy uses a couple of DEFAULT entries so that find_user works, then
passes off the request using the Auth-Type construct to an AuthBy
clause in which you can do anything you like.
The extra processing overhead is minimal, as the AuthBy FILE will cache
the DEFAULT lines in memory and will simply do a couple of memory
lookups.
I encourage you to have a look at the code in Radius/AuthGeneric.pm
and Radius/AuthSQL.pm to see what goes on.
I have also copied this mail to Mike for his additional comments.
regards
Hugh
On Friday, Dec 13, 2002, at 22:26 Australia/Melbourne, Toomas Kärner
wrote:
Hi,
So, AuthBy's like:
AuthBy SQL
Identifier AuthBlacklistCheck
DBSourcedbi:mysql:
DBUsername
DBAuth
AuthSelect select MACADDRESS, REPLYMESSAGE from macblacklist where \
MACADDRESS like '%{Calling-Station-Id}' and \
ACTIVE = 'Yes'
AuthColumnDef 0, Service-Type,check
AuthColumnDef 1, Reply-Message,reply
NoDefault
AcceptIfMissing
/AuthBy
and
AuthBy SQL
Identifier AuthUser
DBSource dbi:mysql:
DBUsername
DBAuth
AuthSelect select ACTIVE, WNACCESS, CHECKATTR, PASSWORD,\
REPLYATTR \
from xx where USERNAME ='%n'
AuthColumnDef 0, ETC-Admin-Active, check
AuthColumnDef 1, ETC-Admin-Wireless, check
AuthColumnDef 2, GENERIC, check
AuthColumnDef 3, User-Password, check
AuthColumnDef 4, GENERIC, reply
DefaultSimultaneousUse 1
NoDefault
RejectEmptyPassword
AccountingTable log
AcctColumnDef DATE,Timestamp ,formatted-date,'%Y-%m-%d'
.
.
.
/AuthBy
and realm like
Realm admin
RewriteUsername s/^([^@]+).*/$1/
AuthByPolicy ContinueUntilReject
AuthBy AuthBlacklistCheck
AuthBy AuthUser
/Realm admin
is impossible because AuthBlacklistCheck has nothing to do with
usernames
and that freaks it out to go to loop with DEFAULT? I think that this
is more
than configuration issue and configuration that you gave me is more
like a
workaround that probably takes more load. If this is true that if no
such
thing as username
Re: (RADIATOR) GRIC and HOST clause
Hello Craig - I think there may be some misunderstanding about what happens with GRIC. There are two parts to any roaming configuration. The first part is for your customers who are roaming internationally, and who are dialling in to ISP's in other parts of the world. These customers' radius requests get forwarded to GRIC who then forward them on to you for authentication. This part is controlled by the Client clasus(s) for the GRIC proxy(s). The second part is for international roaming customers who are dialling in to your NAS infrastructure. For this you generally configure a Realm DEFAULT clause to forward those requests outbound to the GRIC proxy which will then forward them to the target ISP. If you have any other questions, I will try to provide anwers. regards Hugh PS - when would you like me to come over there to run a Radiator training course? :-) On Thursday, Dec 19, 2002, at 01:48 Australia/Melbourne, Craig Gittens wrote: Hi, I was just wondering if this would work since I define my Clients in a SQL DB and the NAS clients are going to be the same for all dialup parties. (Your GRIC example in the Ref Manual assumes you have a different client defined for the GRIC customers.) Realm DEFAULT AuthBy RADIUS Host a.b.c.d Secret IgnoreAcctSignature (This isn't included in the Ref Manual as being a valid entry here) /Host /AuthBy /Realm I somehow don't think this will work since it is a client clause and not a radius clause so how do I work around my NAS and IgnoreAcctSignature? If I included it in the SQL table would it make a difference for my regular realms? I read the REF guide on this flag but I am a bit daft and don't understand the implications of it being put in for a NAS that DOESN'T need it. Craig. === 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: 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.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
