Re: (RADIATOR) Using Called ID to make connect 33.6k

2002-08-19 Thread Hugh Irvine

Hello Matthew -

Yes, but you will need to configure your NAS's to use Pre-Authentication 
to do it properly.

Do your NAS's support Per-Authentication (and subsequently forcing a 
connect speed)?

regards

Hugh


On Sunday, August 18, 2002, at 03:40 PM, mhobbs wrote:

 Hi

 Is it possible to set up Radiator so that when a customer dials up a
 differnet no. from the standard dial up no.
 ie standard is 02991 then they dial 029910001 that Radius sets up 
 the
 call up at 33.6k only ?

 My current set up is below
 Realm DEFAULT
   AuthBy EMERALD
 ..
   /AuthBy
 /Realm

 SessionDatabase SQL
 ..
 /SessionDatabase

 Thanks for your help
 Matthew

 ===
 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.



(RADIATOR) Accounting Handled

2002-08-19 Thread rcortez

Hi,



 On Accounting Handled parameters can I still get an accounting 
stop? Is the Accounting Handled parameter is only use for 
retransmission request?


Ray

===
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 Database failover.

2002-08-19 Thread Achint Saxena
Title: Message



Hi,

Just a quick 
question. I've got a pretty straightforward configuration here. I have my radius 
servers pointed to 2 SQL databases.
When database A 
goes down, Radiator switches over to database B. This works fine. 


My question is, is 
there anyway to go back to database A when it returns to operational? The 
current behaviour is to stay put at database B until it goes down too. 
FailureBackoffTime doesnt work in this way.

Any 
ideas.

Thanks.

Achint.


(RADIATOR) DefaultLeasePeriod

2002-08-19 Thread Ayotunde Itayemi



Hi Hugh, Hi All,

What happens when the DefaultLeasePeriod(say 86400 = 1 day) expires?
Does the user get disconnected and the IP allocated 
to him/her reclaimed?
Or is the user (correctly) allowed to stay 
connected?

Let's assume that the checkattribute of the clients 
specifies that he/she 
can stay on for the whole day (Service-Type = 
Framed-User,Time ="Al-2400",Simultaneous-Use = 1)

Regards,
Tunde I.



(RADIATOR) Re: DefaultLeasePeriod

2002-08-19 Thread Hugh Irvine
 Hello Tunde -

The IP address in the address pool is marked as available when the DefaultLeasePeriod expires.

There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration.

regards

Hugh



On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:

Hi Hugh, Hi All,
 
What happens when the DefaultLeasePeriod  (say 86400 = 1 day) expires?
Does the user get disconnected and the IP allocated to him/her reclaimed?
Or is the user (correctly) allowed to stay connected?
 
Let's assume that the checkattribute of the clients specifies that he/she
can stay on for the whole day (Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1)
 
Regards,
Tunde I.
 

-- 
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) SQL Database failover.

2002-08-19 Thread Hugh Irvine
 Hello Achint -

There is no way in Radiator itself to go back to using database A when it comes back.

Note that you could just define two seperate AuthBy SQL clauses, but I don't know if this will work for you.

Most operators tend to use a single database on some sort of high-availability hardware.

regards

Hugh


On Monday, August 19, 2002, at 05:19 PM, Achint Saxena wrote:

Hi,
 
Just a quick question. I've got a pretty straightforward configuration here. I have my radius servers pointed to 2 SQL databases.
When database A goes down, Radiator switches over to database B. This works fine.
 
My question is, is there anyway to go back to database A when it returns to operational? The current behaviour is to stay put at database B until it goes down too. FailureBackoffTime doesnt work in this way.
 
Any ideas.
 
Thanks.
 
Achint.

-- 
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) Accounting Handled

2002-08-19 Thread Hugh Irvine


Hello Ray -

The AccountingHandled parameter just causes an Accounting-Respnse to be 
sent immediately.

You will still receive all accounting requests sent to this Radiator 
instance.

regards

Hugh


On Monday, August 19, 2002, at 05:13 PM, [EMAIL PROTECTED] wrote:

 Hi,



  On Accounting Handled parameters can I still get an accounting
 stop? Is the Accounting Handled parameter is only use for
 retransmission request?


 Ray

 ===
 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.



Re: (RADIATOR) Re: DefaultLeasePeriod

2002-08-19 Thread Ayotunde Itayemi



Hi Hugh,

One, I assume the checkattribute ( Service-Type = 
Framed-User,Time ="Al-2400",Simultaneous-Use = 1)
implies "always-on 24-7-365" access for the 
user?

My aim is to allow clients with DSL access 
(alwayson-24-7-365)to remain on without 
radiatiorreclaiming the 
IP address allocated to 
themwhile they are still connected.

What combination of attributes do you think can 
handle clients with DSL access (alwayson-24-7-365) and dial-up
access so that the IP address is not reclaimed for 
the DSL clients while they are still connected - and still reclaim
the IP addresses allocated to the dial-up/DSL 
clients when they disconnect by themselves from the NASes?

Would setting the Defaultleaseperiod to "infinity" 
( :-) or say a year, and leaving the LeaseReclaimInterval set to 
(say) a day handle 
the kind of configuration I mentioned above? That is, correctly reclaim the 
IPaddresses for clients
when they are disconnected (by NAS, attributes, 
etc) and also not reclaim the IP addresses allocated to clients
that are still online.

Regards,
Tunde Itayemi.


  - Original Message - 
  From: 
  Hugh Irvine 

  To: Ayotunde Itayemi 
  Cc: [EMAIL PROTECTED] 
  Sent: Monday, August 19, 2002 12:31 
  PM
  Subject: (RADIATOR) Re: 
  DefaultLeasePeriod
  Hello Tunde -The IP address in the address 
  pool is marked as available when the DefaultLeasePeriod expires.There 
  is no relationship between the Session-Timeout on the NAS and the 
  DefaultLeasePeriod for the IP address allocation. You will have to manage any 
  relationship that you wish to have with your 
  configuration.regardsHughOn Monday, August 19, 
  2002, at 06:09 PM, Ayotunde Itayemi wrote:
  Hi Hugh, Hi All,What 
happens when the DefaultLeasePeriod(say 86400 = 1 day) expires?Does 
the user get disconnected and the IP allocated to him/her reclaimed?Or 
is the user (correctly) allowed to stay 
connected?Let's 
assume that the checkattribute of the clients specifies that he/shecan 
stay on for the whole day (Service-Type = Framed-User,Time 
="Al-2400",Simultaneous-Use = 1)Regards,Tunde 
I.-- Radiator: the 
  most portable, flexible and configurable RADIUS serveranywhere. 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) Re: DefaultLeasePeriod

2002-08-19 Thread Ingvar Berg (EAB)

Does anyone know how to set up clients, NAS etc to make the client use a DHCP server 
at the ISP? Is it as simple as doing a normal DHCP configuration in the client, and 
then set up your DHCP server? Or do you have to configure the NAS as well? Because 
such a setup would allow the client to renew its own IP address according to the lease 
time configured in the DHCP server.

/Ingvar

  -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
 
 Hi Hugh,
  
 One, I assume the checkattribute ( Service-Type = 
 Framed-User,Time =Al-2400,Simultaneous-Use = 1)
 implies always-on 24-7-365 access for the user?
  
 My aim is to allow clients with DSL access 
 (alwayson-24-7-365) to remain on without radiatior reclaiming the 
 IP address allocated to them while they are still connected.
  
 What combination of attributes do you think can handle 
 clients with DSL access (alwayson-24-7-365) and dial-up
 access so that the IP address is not reclaimed for the DSL 
 clients while they are still connected - and still reclaim
 the IP addresses allocated to the dial-up/DSL clients when 
 they disconnect by themselves from the NASes?
  
 Would setting the Defaultleaseperiod to infinity ( :-) or 
 say a year, and leaving the LeaseReclaimInterval set to 
 (say) a day handle the kind of configuration I mentioned 
 above? That is, correctly reclaim the IPaddresses for clients
 when they are disconnected (by NAS, attributes, etc) and also 
 not reclaim the IP addresses allocated to clients
 that are still online.
  
 Regards,
 Tunde Itayemi.
  
 
 - Original Message - 
 From: Hugh Irvine mailto:[EMAIL PROTECTED] 
 To: Ayotunde Itayemi mailto:[EMAIL PROTECTED] 
 Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 19, 2002 12:31 PM
 Subject: (RADIATOR) Re: DefaultLeasePeriod
 
 
 Hello Tunde -
 
 The IP address in the address pool is marked as available 
 when the DefaultLeasePeriod expires.
 
 There is no relationship between the Session-Timeout on the 
 NAS and the DefaultLeasePeriod for the IP address allocation. 
 You will have to manage any relationship that you wish to 
 have with your configuration.
 
 regards
 
 Hugh
 
 
 
 On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:
 
 
 
 Hi Hugh, Hi All,
  
 What happens when the DefaultLeasePeriod  (say 86400 = 1 day) expires?
 Does the user get disconnected and the IP allocated to 
 him/her reclaimed?
 Or is the user (correctly) allowed to stay connected?
  
 Let's assume that the checkattribute of the clients specifies 
 that he/she
 can stay on for the whole day (Service-Type = 
 Framed-User,Time =Al-2400,Simultaneous-Use = 1)
  
 Regards,
 Tunde I.
  
 
 
 
 -- 
 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.



Re: (RADIATOR) Re: DefaultLeasePeriod

2002-08-19 Thread Hugh Irvine
 Hello Tunde -

By definition a customer with a permanent connection would not use a dynamic address.

You should allocate such users static addresses instead.

regards

Hugh


On Monday, August 19, 2002, at 10:10 PM, Ayotunde Itayemi wrote:

Hi Hugh,
 
One, I assume the checkattribute ( Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1)
implies "always-on 24-7-365" access for the user?
 
My aim is to allow clients with DSL access (alwayson-24-7-365) to remain on without radiatior reclaiming the
IP address allocated to them while they are still connected.
 
What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up
access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim
the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes?
 
Would setting the Defaultleaseperiod to "infinity" ( :-) or say a year, and leaving the LeaseReclaimInterval set to
(say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients
when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients
that are still online.
 
Regards,
Tunde Itayemi.
 

- Original Message -
From: Hugh Irvine
To: Ayotunde Itayemi
Cc: [EMAIL PROTECTED]
Sent: Monday, August 19, 2002 12:31 PM
Subject: (RADIATOR) Re: DefaultLeasePeriod

Hello Tunde -

The IP address in the address pool is marked as available when the DefaultLeasePeriod expires.

There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration.

regards

Hugh



On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:

Hi Hugh, Hi All,
 
What happens when the DefaultLeasePeriod  (say 86400 = 1 day) expires?
Does the user get disconnected and the IP allocated to him/her reclaimed?
Or is the user (correctly) allowed to stay connected?
 
Let's assume that the checkattribute of the clients specifies that he/she
can stay on for the whole day (Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1)
 
Regards,
Tunde I.
 

--
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.


-- 
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) Re: DefaultLeasePeriod

2002-08-19 Thread Hugh Irvine


Hello Ingvar -

No I have never seen such a thing.

This is because the end client device must start a session (usually PPP) 
*before* it can send TCP/UDP packets.

regards

Hugh


On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote:

 Does anyone know how to set up clients, NAS etc to make the client use 
 a DHCP server at the ISP? Is it as simple as doing a normal DHCP 
 configuration in the client, and then set up your DHCP server? Or do 
 you have to configure the NAS as well? Because such a setup would allow 
 the client to renew its own IP address according to the lease time 
 configured in the DHCP server.

 /Ingvar

  -Original Message-
 From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]

 Hi Hugh,

 One, I assume the checkattribute ( Service-Type =
 Framed-User,Time =Al-2400,Simultaneous-Use = 1)
 implies always-on 24-7-365 access for the user?

 My aim is to allow clients with DSL access
 (alwayson-24-7-365) to remain on without radiatior reclaiming the
 IP address allocated to them while they are still connected.

 What combination of attributes do you think can handle
 clients with DSL access (alwayson-24-7-365) and dial-up
 access so that the IP address is not reclaimed for the DSL
 clients while they are still connected - and still reclaim
 the IP addresses allocated to the dial-up/DSL clients when
 they disconnect by themselves from the NASes?

 Would setting the Defaultleaseperiod to infinity ( :-) or
 say a year, and leaving the LeaseReclaimInterval set to
 (say) a day handle the kind of configuration I mentioned
 above? That is, correctly reclaim the IPaddresses for clients
 when they are disconnected (by NAS, attributes, etc) and also
 not reclaim the IP addresses allocated to clients
 that are still online.

 Regards,
 Tunde Itayemi.


 - Original Message -
 From: Hugh Irvine mailto:[EMAIL PROTECTED]
 To: Ayotunde Itayemi mailto:[EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
 Sent: Monday, August 19, 2002 12:31 PM
 Subject: (RADIATOR) Re: DefaultLeasePeriod


 Hello Tunde -

 The IP address in the address pool is marked as available
 when the DefaultLeasePeriod expires.

 There is no relationship between the Session-Timeout on the
 NAS and the DefaultLeasePeriod for the IP address allocation.
 You will have to manage any relationship that you wish to
 have with your configuration.

 regards

 Hugh



 On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:



 Hi Hugh, Hi All,

 What happens when the DefaultLeasePeriod  (say 86400 = 1 day) expires?
 Does the user get disconnected and the IP allocated to
 him/her reclaimed?
 Or is the user (correctly) allowed to stay connected?

 Let's assume that the checkattribute of the clients specifies
 that he/she
 can stay on for the whole day (Service-Type =
 Framed-User,Time =Al-2400,Simultaneous-Use = 1)

 Regards,
 Tunde I.




--
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.


===
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) Re: DefaultLeasePeriod

2002-08-19 Thread Ingvar Berg (EAB)

Just thought that it would be A Nice Thing, if the NAS could act as a DHCP relay, and 
leave it to the client and the DHCP server to do this the standard way. (A Nice Thing 
usually exists already, and can be found, you just have to know where to search ;-).

/Ingvar

 -Original Message-
 From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
 
 Hello Ingvar -
 
 No I have never seen such a thing.
 
 This is because the end client device must start a session 
 (usually PPP) 
 *before* it can send TCP/UDP packets.
 
 regards
 
 Hugh
 
 
 On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote:
 
  Does anyone know how to set up clients, NAS etc to make the 
 client use 
  a DHCP server at the ISP? Is it as simple as doing a normal DHCP 
  configuration in the client, and then set up your DHCP 
 server? Or do 
  you have to configure the NAS as well? Because such a setup 
 would allow 
  the client to renew its own IP address according to the lease time 
  configured in the DHCP server.
 
  /Ingvar
 
   -Original Message-
  From:  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 
  Hi Hugh,
 
  One, I assume the checkattribute ( Service-Type =
  Framed-User,Time =Al-2400,Simultaneous-Use = 1)
  implies always-on 24-7-365 access for the user?
 
  My aim is to allow clients with DSL access
  (alwayson-24-7-365) to remain on without radiatior reclaiming the
  IP address allocated to them while they are still connected.
 
  What combination of attributes do you think can handle
  clients with DSL access (alwayson-24-7-365) and dial-up
  access so that the IP address is not reclaimed for the DSL
  clients while they are still connected - and still reclaim
  the IP addresses allocated to the dial-up/DSL clients when
  they disconnect by themselves from the NASes?
 
  Would setting the Defaultleaseperiod to infinity ( :-) or
  say a year, and leaving the LeaseReclaimInterval set to
  (say) a day handle the kind of configuration I mentioned
  above? That is, correctly reclaim the IPaddresses for clients
  when they are disconnected (by NAS, attributes, etc) and also
  not reclaim the IP addresses allocated to clients
  that are still online.
 
  Regards,
  Tunde Itayemi.
 
 
  - Original Message -
  From: Hugh Irvine mailto:[EMAIL PROTECTED]
  To: Ayotunde Itayemi mailto:[EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
  Sent: Monday, August 19, 2002 12:31 PM
  Subject: (RADIATOR) Re: DefaultLeasePeriod
 
 
  Hello Tunde -
 
  The IP address in the address pool is marked as available
  when the DefaultLeasePeriod expires.
 
  There is no relationship between the Session-Timeout on the
  NAS and the DefaultLeasePeriod for the IP address allocation.
  You will have to manage any relationship that you wish to
  have with your configuration.
 
  regards
 
  Hugh
 
 
 
  On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:
 
 
 
  Hi Hugh, Hi All,
 
  What happens when the DefaultLeasePeriod  (say 86400 = 1 
 day) expires?
  Does the user get disconnected and the IP allocated to
  him/her reclaimed?
  Or is the user (correctly) allowed to stay connected?
 
  Let's assume that the checkattribute of the clients specifies
  that he/she
  can stay on for the whole day (Service-Type =
  Framed-User,Time =Al-2400,Simultaneous-Use = 1)
 
  Regards,
  Tunde I.
 
 
 
 
 --
 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.
 
 
===
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) Re: DefaultLeasePeriod

2002-08-19 Thread Ayotunde Itayemi



Hi Hugh,

Okay you are right. But what if I would like to 
ensure that the max time a client can stay
on is a day? That is, even the "always-on" clients 
get disconnected at least once everyday?
In such a case, what would my checkattributes and 
replyattributes be?

Regards,
Tunde I.


  - Original Message - 
  From: 
  Hugh Irvine 

  To: Ayotunde Itayemi 
  Cc: [EMAIL PROTECTED] 
  Sent: Monday, August 19, 2002 2:48 
  PM
  Subject: Re: (RADIATOR) Re: 
  DefaultLeasePeriod
  Hello Tunde -By 
  definition a customer with a permanent connection would not use a dynamic 
  address.You should allocate such users static addresses 
  instead.regardsHughOn Monday, August 19, 2002, at 
  10:10 PM, Ayotunde Itayemi wrote:
  Hi Hugh,One, 
I assume the checkattribute ( Service-Type = Framed-User,Time 
="Al-2400",Simultaneous-Use = 1)implies 
"always-on 24-7-365" access for the 
user?My 
aim is to allow clients with DSL access (alwayson-24-7-365)to remain 
on without radiatiorreclaiming theIP 
address allocated to themwhile they are still connected.What 
combination of attributes do you think can handle clients with DSL access 
(alwayson-24-7-365) and dial-upaccess 
so that the IP address is not reclaimed for the DSL clients while they are 
still connected - and still reclaimthe 
IP addresses allocated to the dial-up/DSL clients when they disconnect by 
themselves from the NASes?Would 
setting the Defaultleaseperiod to "infinity" ( :-) or say a year, and 
leaving the LeaseReclaimInterval set to(say) a 
day handle the kind of configuration I mentioned above? That is, correctly 
reclaim the IPaddresses for clientswhen 
they are disconnected (by NAS, attributes, etc) and also not reclaim the IP 
addresses allocated to clientsthat 
are still online.Regards,Tunde 
Itayemi.- Original Message 
-From: Hugh 
IrvineTo: Ayotunde 
ItayemiCc: 
[EMAIL PROTECTED]Sent: 
Monday, August 19, 2002 12:31 PMSubject: (RADIATOR) Re: 
DefaultLeasePeriodHello Tunde -The IP address in the address 
pool is marked as available when the DefaultLeasePeriod 
expires.There is no relationship between the Session-Timeout on the 
NAS and the DefaultLeasePeriod for the IP address allocation. You will have 
to manage any relationship that you wish to have with your 
configuration.regardsHughOn Monday, August 
19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:Hi Hugh, Hi 
All,What happens when the DefaultLeasePeriod(say 
86400 = 1 day) expires?Does the user get disconnected and the IP 
allocated to him/her reclaimed?Or is the user (correctly) allowed to 
stay connected?Let's assume that the checkattribute of the 
clients specifies that he/shecan stay on for the whole day (Service-Type 
= Framed-User,Time ="Al-2400",Simultaneous-Use = 
1)Regards,Tunde I.--Radiator: the 
most portable, flexible and configurable RADIUS serveranywhere. 
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.-- Radiator: the most portable, 
  flexible and configurable RADIUS serveranywhere. 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.


(RADIATOR) Attribute Number 79

2002-08-19 Thread William Hernandez

Hello everyone,

I'm testing our upgrade to 3.1 and I'm getting

ERR: Attribute number 79 is not defined in your dictionary

I get the error with the 'dictionary' file from the 3.1 release. At this
point we're just testing with radpwtst so I didn't think it was a vendor
specific attribute, but I also get the error with a concatenation of
'dictionary' and 'dictionary.usr' and 'dictionary.ascend2' (since we
have both ascend and total control hardware).  And I also get the error
with the 'dictionary' file that we were using with Radiator 2.18.2.

Thanks in advance,
William

===
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) Malformed request packet: Attribute 25 with length 1: ignored

2002-08-19 Thread William Hernandez

Hugh,

The class string is set in a PostAuthHook. We're now using Perl 5.6.1,
Freetds 0.60 and DBD:Sybase 0.94. I was able to reproduce the problem
outside of Radiator directly in Perl so I've concluded it's not a
Radiator problem.

When we were using Radiator 2.1.8.2, Perl 5.6.0, Freetds 0.52,
DBD:Sybase 0.91 we weren't getting this error. As a work-around I
modified the PostAuthHook to strip the null characters at the end of the
strings. Perhaps you do this already in the Radiator 3.1 code.

Thanks in advance,
William


-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]] 
Sent: Friday, August 16, 2002 10:02 PM
To: William Hernandez
Cc: Radiator (Radiator)
Subject: Re: (RADIATOR) Malformed request packet: Attribute 25 with
length 1: ignored



Hello William -

I will need to see a more complete trace 5 debug (including hex dumps) 
of the incoming request, the corresponding access accept and the 
subsequent accounting requests. I will also need a copy of the 
configuration file (no secrets) and a copy of the relevant user record.

Just looking at what you have included, it looks like the Class 
attribute is being set incorrectly by your configuration.

regards

Hugh


On Saturday, August 17, 2002, at 04:18 AM, William Hernandez wrote:

 Hello everyone,

 I've just installed Radiator 3.1 plus patches on RedHat 7.3.

 Our users are authenticating, but I'm getting the following on every
 request:

 Malformed request packet: Attribute 25 with length 1: ignored

 The trace 4 output has:
 Fri Aug 16 14:10:45 2002: DEBUG: User whr has content controls of
 xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS GAMB HATE OBSC PORN

 RRATED I, 1
 Code:   Access-Accept
 Identifier: 0
 Authentic:  1234567890123456
 Attributes:
 Service-Type = Framed-User
 Framed-Protocol = PPP
 Framed-IP-Netmask = 255.255.255.255
 Framed-Compression = Van-Jacobson-TCP-IP
 Ascend-Idle-Limit = 900
 Service-Type = Framed-User
 Framed-Protocol = MP
 Framed-IP-Netmask = 255.255.255.255
 Framed-Compression = Van-Jacobson-TCP-IP
 Ascend-Maximum-Channels = 2
 Ascend-Idle-Limit = 1200
 Idle-Timeout = 1200
 Session-Timeout = 31800
 Class = xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS 
 GAMB HATE OB SC PORN RRATED I,
 1
 
 0
 000
 000
 0
 000
 000
 0
 00
 
 0
 000
 000
 0
 000
 000

 Our dictionary file (a concatenation of dictionary and
 dictionary.ascend2) has:
 ATTRIBUTE   Class   25  string

 What is causing the Malformed request packet?

 Thanks in advance,
 William

 ===
 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.



RE: (RADIATOR) Attribute Number 79

2002-08-19 Thread William Hernandez

Hello everyone,

Found the following in the archive which solved the problem.

# Some experimental attributes from RFC 2869:
ATTRIBUTE   Prompt  76  integer
ATTRIBUTE   Connect-Info77  string
ATTRIBUTE   Configuration-Token 78  binary
ATTRIBUTE   EAP-Message 79  binary
ATTRIBUTE   Signature   80  binary
ATTRIBUTE   Message-Authenticator   80  binary
ATTRIBUTE   Acct-Interim-Interval   85  integer
ATTRIBUTE   Ascend-Owner-IP-Addr86  ipaddr
ATTRIBUTE   NAS-Port-Id 87  string
ATTRIBUTE   Framed-Pool 88  string

Thanks,
William

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of William Hernandez
Sent: Monday, August 19, 2002 10:42 AM
To: Radiator (Radiator)
Subject: (RADIATOR) Attribute Number 79


Hello everyone,

I'm testing our upgrade to 3.1 and I'm getting

ERR: Attribute number 79 is not defined in your dictionary

I get the error with the 'dictionary' file from the 3.1 release. At this
point we're just testing with radpwtst so I didn't think it was a vendor
specific attribute, but I also get the error with a concatenation of
'dictionary' and 'dictionary.usr' and 'dictionary.ascend2' (since we
have both ascend and total control hardware).  And I also get the error
with the 'dictionary' file that we were using with Radiator 2.18.2.

Thanks in advance,
William

===
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) Re: DefaultLeasePeriod

2002-08-19 Thread Claudio Lapidus

Hello Ingvar,

I think perhaps it will depend heavily on the capabilities of the NAS itself 
to do such a thing. If you are talking Cisco here, the NAS has all the same 
capabilities as a standard router. At least I can recall a setup we did once 
in the past where we allowed DHCP broadcast queries to leak from one LAN 
across a serial link and on the other side, to the DHCP server. There was a 
command named 'ip helper address' I think, don't recall very well, though. 
Perhaps this is a starting point for your quest :)  Now, if you are talking 
about other NAS brands here, I won't be able to help.

regards,
cl.


From: Ingvar Berg (EAB) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: (RADIATOR) Re: DefaultLeasePeriod
Date: Mon, 19 Aug 2002 16:18:26 +0200

Just thought that it would be A Nice Thing, if the NAS could act as a DHCP 
relay, and leave it to the client and the DHCP server to do this the 
standard way. (A Nice Thing usually exists already, and can be found, you 
just have to know where to search ;-).

/Ingvar

  -Original Message-
  From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
 
  Hello Ingvar -
 
  No I have never seen such a thing.
 
  This is because the end client device must start a session
  (usually PPP)
  *before* it can send TCP/UDP packets.
 
  regards
 
  Hugh
 
 
  On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote:
 
   Does anyone know how to set up clients, NAS etc to make the
  client use
   a DHCP server at the ISP? Is it as simple as doing a normal DHCP
   configuration in the client, and then set up your DHCP
  server? Or do
   you have to configure the NAS as well? Because such a setup
  would allow
   the client to renew its own IP address according to the lease time
   configured in the DHCP server.
  
   /Ingvar
  
-Original Message-
   From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
  
   Hi Hugh,
  
   One, I assume the checkattribute ( Service-Type =
   Framed-User,Time =Al-2400,Simultaneous-Use = 1)
   implies always-on 24-7-365 access for the user?
  
   My aim is to allow clients with DSL access
   (alwayson-24-7-365) to remain on without radiatior reclaiming the
   IP address allocated to them while they are still connected.
  
   What combination of attributes do you think can handle
   clients with DSL access (alwayson-24-7-365) and dial-up
   access so that the IP address is not reclaimed for the DSL
   clients while they are still connected - and still reclaim
   the IP addresses allocated to the dial-up/DSL clients when
   they disconnect by themselves from the NASes?
  
   Would setting the Defaultleaseperiod to infinity ( :-) or
   say a year, and leaving the LeaseReclaimInterval set to
   (say) a day handle the kind of configuration I mentioned
   above? That is, correctly reclaim the IPaddresses for clients
   when they are disconnected (by NAS, attributes, etc) and also
   not reclaim the IP addresses allocated to clients
   that are still online.
  
   Regards,
   Tunde Itayemi.
  
  
   - Original Message -
   From: Hugh Irvine mailto:[EMAIL PROTECTED]
   To: Ayotunde Itayemi mailto:[EMAIL PROTECTED]
   Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
   Sent: Monday, August 19, 2002 12:31 PM
   Subject: (RADIATOR) Re: DefaultLeasePeriod
  
  
   Hello Tunde -
  
   The IP address in the address pool is marked as available
   when the DefaultLeasePeriod expires.
  
   There is no relationship between the Session-Timeout on the
   NAS and the DefaultLeasePeriod for the IP address allocation.
   You will have to manage any relationship that you wish to
   have with your configuration.
  
   regards
  
   Hugh
  
  
  
   On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:
  
  
  
   Hi Hugh, Hi All,
  
   What happens when the DefaultLeasePeriod  (say 86400 = 1
  day) expires?
   Does the user get disconnected and the IP allocated to
   him/her reclaimed?
   Or is the user (correctly) allowed to stay connected?
  
   Let's assume that the checkattribute of the clients specifies
   that he/she
   can stay on for the whole day (Service-Type =
   Framed-User,Time =Al-2400,Simultaneous-Use = 1)
  
   Regards,
   Tunde I.
  
  
  
  
  --
  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.
  
 
===
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) Malformed request packet: Attribute 25 with length 1: ignored

2002-08-19 Thread Hugh Irvine


Hello William -

Is there anything else I can help you with?

regards

Hugh


On Tuesday, August 20, 2002, at 12:59 AM, William Hernandez wrote:

 Hugh,

 The class string is set in a PostAuthHook. We're now using Perl 5.6.1,
 Freetds 0.60 and DBD:Sybase 0.94. I was able to reproduce the problem
 outside of Radiator directly in Perl so I've concluded it's not a
 Radiator problem.

 When we were using Radiator 2.1.8.2, Perl 5.6.0, Freetds 0.52,
 DBD:Sybase 0.91 we weren't getting this error. As a work-around I
 modified the PostAuthHook to strip the null characters at the end of the
 strings. Perhaps you do this already in the Radiator 3.1 code.

 Thanks in advance,
 William


 -Original Message-
 From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
 Sent: Friday, August 16, 2002 10:02 PM
 To: William Hernandez
 Cc: Radiator (Radiator)
 Subject: Re: (RADIATOR) Malformed request packet: Attribute 25 with
 length 1: ignored



 Hello William -

 I will need to see a more complete trace 5 debug (including hex dumps)
 of the incoming request, the corresponding access accept and the
 subsequent accounting requests. I will also need a copy of the
 configuration file (no secrets) and a copy of the relevant user record.

 Just looking at what you have included, it looks like the Class
 attribute is being set incorrectly by your configuration.

 regards

 Hugh


 On Saturday, August 17, 2002, at 04:18 AM, William Hernandez wrote:

 Hello everyone,

 I've just installed Radiator 3.1 plus patches on RedHat 7.3.

 Our users are authenticating, but I'm getting the following on every
 request:

 Malformed request packet: Attribute 25 with length 1: ignored

 The trace 4 output has:
 Fri Aug 16 14:10:45 2002: DEBUG: User whr has content controls of
 xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS GAMB HATE OBSC PORN

 RRATED I, 1
 Code:   Access-Accept
 Identifier: 0
 Authentic:  1234567890123456
 Attributes:
 Service-Type = Framed-User
 Framed-Protocol = PPP
 Framed-IP-Netmask = 255.255.255.255
 Framed-Compression = Van-Jacobson-TCP-IP
 Ascend-Idle-Limit = 900
 Service-Type = Framed-User
 Framed-Protocol = MP
 Framed-IP-Netmask = 255.255.255.255
 Framed-Compression = Van-Jacobson-TCP-IP
 Ascend-Maximum-Channels = 2
 Ascend-Idle-Limit = 1200
 Idle-Timeout = 1200
 Session-Timeout = 31800
 Class = xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS
 GAMB HATE OB SC PORN RRATED I,
 1
 
 0
 000
 000
 0
 000
 000
 0
 00
 
 0
 000
 000
 0
 000
 000

 Our dictionary file (a concatenation of dictionary and
 dictionary.ascend2) has:
 ATTRIBUTE   Class   25  string

 What is causing the Malformed request packet?

 Thanks in advance,
 William

 ===
 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.


--
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.



Re: (RADIATOR) Attribute Number 79

2002-08-19 Thread Hugh Irvine


Hello William -

These attributes are included in the latest Radiator 3.1 dictionary.

regards

Hugh


On Tuesday, August 20, 2002, at 01:31 AM, William Hernandez wrote:

 Hello everyone,

 Found the following in the archive which solved the problem.

 # Some experimental attributes from RFC 2869:
 ATTRIBUTE   Prompt  76  integer
 ATTRIBUTE   Connect-Info77  string
 ATTRIBUTE   Configuration-Token 78  binary
 ATTRIBUTE   EAP-Message 79  binary
 ATTRIBUTE   Signature   80  binary
 ATTRIBUTE   Message-Authenticator   80  binary
 ATTRIBUTE   Acct-Interim-Interval   85  integer
 ATTRIBUTE   Ascend-Owner-IP-Addr86  ipaddr
 ATTRIBUTE   NAS-Port-Id 87  string
 ATTRIBUTE   Framed-Pool 88  string

 Thanks,
 William

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
 Behalf Of William Hernandez
 Sent: Monday, August 19, 2002 10:42 AM
 To: Radiator (Radiator)
 Subject: (RADIATOR) Attribute Number 79


 Hello everyone,

 I'm testing our upgrade to 3.1 and I'm getting

 ERR: Attribute number 79 is not defined in your dictionary

 I get the error with the 'dictionary' file from the 3.1 release. At this
 point we're just testing with radpwtst so I didn't think it was a vendor
 specific attribute, but I also get the error with a concatenation of
 'dictionary' and 'dictionary.usr' and 'dictionary.ascend2' (since we
 have both ascend and total control hardware).  And I also get the error
 with the 'dictionary' file that we were using with Radiator 2.18.2.

 Thanks in advance,
 William

 ===
 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: 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.



Re: (RADIATOR) Re: DefaultLeasePeriod

2002-08-19 Thread Hugh Irvine


Hello Claudio, Hello Ingvar -

As mentioned in my previous mail, DHCP as a protocol uses UDP, which 
assumes that you already have a properly configured and operating IP 
stack in place. This is obviously not the case in most cases when 
Radiator is handling an access request for PPP for example, because the 
result of the radius authentication will result in the link being set up.

As Ingvar already knows, we have implemented the AuthBy 
DYNADDRESS/AddressAllocator DHCP combination to allow a DHCP server to 
be used for address allocation in response to a radius request.

If as Claudio describes, you are wanting to do DHCP over an already 
established link, then you can use DHCP request forwarding using Cisco's 
selective forwarding configuration.

regards

Hugh



On Tuesday, August 20, 2002, at 02:08 AM, Claudio Lapidus wrote:

 Hello Ingvar,

 I think perhaps it will depend heavily on the capabilities of the NAS 
 itself to do such a thing. If you are talking Cisco here, the NAS has 
 all the same capabilities as a standard router. At least I can recall a 
 setup we did once in the past where we allowed DHCP broadcast queries 
 to leak from one LAN across a serial link and on the other side, to 
 the DHCP server. There was a command named 'ip helper address' I think, 
 don't recall very well, though. Perhaps this is a starting point for 
 your quest :)  Now, if you are talking about other NAS brands here, I 
 won't be able to help.

 regards,
 cl.


 From: Ingvar Berg (EAB) [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: RE: (RADIATOR) Re: DefaultLeasePeriod
 Date: Mon, 19 Aug 2002 16:18:26 +0200

 Just thought that it would be A Nice Thing, if the NAS could act as a 
 DHCP relay, and leave it to the client and the DHCP server to do this 
 the standard way. (A Nice Thing usually exists already, and can be 
 found, you just have to know where to search ;-).

 /Ingvar

  -Original Message-
  From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
 
  Hello Ingvar -
 
  No I have never seen such a thing.
 
  This is because the end client device must start a session
  (usually PPP)
  *before* it can send TCP/UDP packets.
 
  regards
 
  Hugh
 
 
  On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote:
 
   Does anyone know how to set up clients, NAS etc to make the
  client use
   a DHCP server at the ISP? Is it as simple as doing a normal DHCP
   configuration in the client, and then set up your DHCP
  server? Or do
   you have to configure the NAS as well? Because such a setup
  would allow
   the client to renew its own IP address according to the lease time
   configured in the DHCP server.
  
   /Ingvar
  
-Original Message-
   From:   [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
  
   Hi Hugh,
  
   One, I assume the checkattribute ( Service-Type =
   Framed-User,Time =Al-2400,Simultaneous-Use = 1)
   implies always-on 24-7-365 access for the user?
  
   My aim is to allow clients with DSL access
   (alwayson-24-7-365) to remain on without radiatior reclaiming the
   IP address allocated to them while they are still connected.
  
   What combination of attributes do you think can handle
   clients with DSL access (alwayson-24-7-365) and dial-up
   access so that the IP address is not reclaimed for the DSL
   clients while they are still connected - and still reclaim
   the IP addresses allocated to the dial-up/DSL clients when
   they disconnect by themselves from the NASes?
  
   Would setting the Defaultleaseperiod to infinity ( :-) or
   say a year, and leaving the LeaseReclaimInterval set to
   (say) a day handle the kind of configuration I mentioned
   above? That is, correctly reclaim the IPaddresses for clients
   when they are disconnected (by NAS, attributes, etc) and also
   not reclaim the IP addresses allocated to clients
   that are still online.
  
   Regards,
   Tunde Itayemi.
  
  
   - Original Message -
   From: Hugh Irvine mailto:[EMAIL PROTECTED]
   To: Ayotunde Itayemi mailto:[EMAIL PROTECTED]
   Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
   Sent: Monday, August 19, 2002 12:31 PM
   Subject: (RADIATOR) Re: DefaultLeasePeriod
  
  
   Hello Tunde -
  
   The IP address in the address pool is marked as available
   when the DefaultLeasePeriod expires.
  
   There is no relationship between the Session-Timeout on the
   NAS and the DefaultLeasePeriod for the IP address allocation.
   You will have to manage any relationship that you wish to
   have with your configuration.
  
   regards
  
   Hugh
  
  
  
   On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:
  
  
  
   Hi Hugh, Hi All,
  
   What happens when the DefaultLeasePeriod  (say 86400 = 1
  day) expires?
   Does the user get disconnected and the IP allocated to
   him/her reclaimed?
   Or is the user (correctly) allowed to stay connected?
  
   Let's assume that the checkattribute of the clients specifies
   that he/she
   can stay on for the whole day (Service-Type 

(RADIATOR) Simultaneous-use in 3.1

2002-08-19 Thread William Hernandez

Hello everyone,

I'm testing 3.1 using radpwtst. And I've noticed the message INFO:
Access rejected for whr: Simultaneous-Use of 2 exceeded in the
radius.log.  The message is correct. The problem is that RADONLINE shows
there are 3 logins.

radpwtst -trace -s localhost -user whr -password x -auth_port 1812
-acct_port 1813 -secret x -dictionary /etc/raddb/dictionary.prw -nostop
-nas_port=1234

radpwtst -trace -s localhost -user whr -password x -auth_port 1812
-acct_port 1813 -secret x -dictionary /etc/raddb/dictionary.prw -nostop
-nas_port=1235

radpwtst -trace -s localhost -user whr -password x -auth_port 1812
-acct_port 1813 -secret x -dictionary /etc/raddb/dictionary.prw -nostop
-nas_port=1236

Output of radwho.cgi
whr 203.63.154.1 1234 1234 Mon Aug 19 15:37:18 2002 0 00:00:47
terminate session delete session 
whr 203.63.154.1 1236 1234 Mon Aug 19 15:37:38 2002 0 00:00:27
terminate session delete session 
whr 203.63.154.1 1235 1234 Mon Aug 19 15:37:30 2002 0 00:00:35
terminate session delete session 

Attached are the radius.cfg and the trace 4 log.

Thanks in advance,
William



radius.log
Description: Binary data


radius.cfg
Description: Binary data


(RADIATOR) Malformed Packet requests

2002-08-19 Thread Achint Saxena

Hello,

Thanks for all your previous replies. Just another issue I need some help
with. Im getting a Malformed request packet warning in my radiator logs. Any
ideas why would this happen? I don't have an Attribute 0 defined in my
dictionary. A sample packet trace is attached.

Cheers.

Achint.

---
Mon Aug 19 15:50:54 2002: WARNING: Malformed request packet: Vendor 5586
Attribute 0 with length 1: ignored
Mon Aug 19 15:50:54 2002: DEBUG: Packet dump:
*** Received from 192.168.193.2 port 1812 
Code:   Accounting-Request
Identifier: 241
Authentic:  151W182231/Ze176135130i204qD133o
Attributes:
Acct-Status-Type = Start
Acct-Delay-Time = 0
Acct-Authentic = RADIUS
Event-Timestamp = 1029736339
Acct-Interim-Interval = 60
NAS-IP-Address = 192.168.193.2
User-Name = new_user
Acct-Session-Id =2949346
L2TP-Tunnel-If-Index = 73
L2TP-Tunnel-Local-Sid = 77
ISP-LNS-Name = r1.nwton
Tier-Of-Service = Business
Unknown = 
--
===
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) NumHosts in SQLRadius

2002-08-19 Thread Martin Edge

Hey Guys,

Is there anyway to set NumHosts dynamically? Say perhaps via the first
SQLRADIUS lookup, it returns the NumHosts variable?

I'd prefer to not have to hard set this, as I'm trying to design the system
around a dynamic number of destination RADIUS servers..

also..

What type of detail can I expect with trying to run StatsLogSQL with
SQLRADIUS, as I would like to be able to scalably count the
request/responses along with the number of downstream ISPs I am supporting.
From what I read in the documentation, statistics are kept for each
Identifier, the SQLRADIUS itself as an Identifier, but each downstream
within the database, I would expect does not have it's own unique
Identifier..

Thanks,
Martin

===
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) socket queue length

2002-08-19 Thread rcortez

Hi,



 Is there any OS parameter or radiator parameter which can be fine 
tune to increase the accounting packet received other than OS 
udp_max_buf and radius socket queue length?


Ray

===
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) socket queue length

2002-08-19 Thread rcortez

Hi,


   
Is there any OS parameter or radiator parameter which can be fine 
tune to increase the accounting packet received other than OS 
udp_max_buf and radius socket queue length? Since the current cpu 
utilization of our server is 98% idle and the physical memory utilized 
is 386K of the current 512K.


Ray

 
 


===
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) Version 3.2 released

2002-08-19 Thread Mike McCauley

We are pleased to announce the release of Radiator version 3.2
This version provides some significant new features and 
some bug fixes. 

Among the most important new features is the support for EAP-TTLS 802.1x 
wireless authentication.

Caution: users of MSCHAP authentication should note the need to install 
Digest::SHA1 prior to installing this new version for continued correct 
operation.

As usual, the new version is available free of charge to current 
licensees from 
http://www.open.com.au/radiator/downloads/Radiator-3.2.tgz
and
http://www.open.com.au/radiator/downloads/Radiator-3.2-1.noarch.rpm

and to current evaluators from 
http://www.open.com.au/radiator/demo-downloads/Radiator-Demo-3.2.tgz
and
http://www.open.com.au/radiator/demo-downloads/Radiator-Demo-3.2-1.noarch.rpm

An extract from the history file is attached

Revision 3.2 (20/8/02 New features and fixes) 

Caution: Updated AuthGeneric.pm and MSCHAP.pm to use more modern
Digest::SHA1 instead of SHA. if you are using SHA passwords or MSCHAP
authentication, you must install Digest::SHA1.

Added new AuthBy URL module, contributed by Mauro Crovato
([EMAIL PROTECTED]). This module authenticates by sending the
username and password (optionally encrypted) as tags to a URL by
HTTP. A CGI or ASP program at the URL authenticates the password.

Fixed some interoperability problems with EAP-TLS. Testing with
Aironet AP and Client cards with OpenSSL and Xsupplicant on Linux and
Windows XP.

Beta support for EAP-TTLS as used by Funk Odyssey clients. Supports
TTLS-PAP, TTLS-CHAP, TTLS-MSCHAP and TTLS-MSCHAPV2 for both local and
proxy authentication. See example configuration files
goodies/eap_ttls.cfg and goodies/eap_ttls_proxy.cfg. TTLS is Tunnelled
TLS, as per draft-ietf-pppext-eap-ttls-01.txt., It is supported by
Funk Odyssey wireless clients through a variety of wireless access
points. It provides one-way TLS authentication (the client
authenticates the radius server), and authentication requests are
delivered securely to the radius server via the encrypted TLS
tunnel. Unlike TLS, TTLS does not _require_ a certificate on each
client.

Tested EAP MD5-Challenge with Aironet AP and Client cards and Windows
XP. Added example goodies/eap_md5.cfg config file.

Added more Spring Tide VSAs to the dictionary.Contributed by
[EMAIL PROTECTED]

AuthBy SQL now runs AuthSQLStatement even if AuthSelect is empty. 

A debug print statement was accidentally left in AuthLog SQL 

AuthBy SQL AcctColumnDef now cannot insert the same column multiple
times. If there are multiple AcctColumnDef definitions for the same
column name and with non-null values, the last one will be the one
inserted. This is most likely to improve the case where there are two
NASIdentifier definitions, and the NAS reports both NAS-IP-Address and
NAS-Identifier. A number of example config files were changed so that
NASIdentifier is preferred if present.

AuthBy SQL now supports HandleAcctStatusTypes parameter, which allows
you to specify a comma separated list of AcctStatusTypes that will be
processed. All other types will by acknowledged, but not inserted or
processed with AcctSQLStatement. This is a more general mechanism than
AccountingStartsOnly, AccountingStopsOnly and AccountingAlivesOnly,
and these parameters are now officially deprecated and will not be
supported in the future.

An typo in Radius.pm prevented Ascend-Xmit-Rate working
properly. Reported by Romain Vergniol ([EMAIL PROTECTED]).

In the event of no reply from any hosts, AuthBy SQLRADIUS now runs the
NoReplyHook before any FailurePolicy automatic reply. Previously it
was run after the automatic reply.

Added Roaring Penguin VSA's to dictionary. Contributed by Scott
Helms . Thanks Scott.

Added to Monitor support for Clients parameter, a comma or space
separated list of IP addresses that Monitor will accept connections
from. Default is to accept from any address.

Added a number of new Altiga VSAs to dictionary, contributed by neil
d. quiogue ([EMAIL PROTECTED])

Added /usr/local/etc/radiator to the dictionary search path for
radpwtst. Suggested by Martin Edge ([EMAIL PROTECTED])

Added UseTLS parameter for forcing TLS encryption in AuthBy
LDAP2. Contributed by Carl Litt ([EMAIL PROTECTED]). Thanks Carl.

Added a new flags to AuthBy NT on Windows. IgnoreAccountExpiry causes
AuthBy NT to ignore the NT account expiry flag when users attempt to
log in. IgnorePasswordExpiry causes it to ignore the password expired
flag. IgnorePasswordChange causes it to ignore the password change
required flag.

radpwtst -gui was not correctly showing packet dumps in the 'Detailed'
trace level.

Fixed a problem where an incorrect data length in an incoming radius
packet could result in reports of a 'Malformed request
packet:'. Reported by Thilo Wunderlich ([EMAIL PROTECTED])

New parameter AuthCheckDN in AuthLDAP2 alows you to specify an
alternative DN to use to check a user's password, instead of the one
returned by the search result. Patch 

Re: (RADIATOR) Re: DefaultLeasePeriod

2002-08-19 Thread Brian Morris



I think in the case of DSL clients though this is 
not quite correct.

We have several 000's of DSL clients but only about 
25% of them are online at any one time. Sure they CAN be permanent, but 
they usually are not.

It is a waste of IP space to allocate a static IP 
to all of them. In some business cases it is even desirous not to allocate 
them a static IP - but rather make itan 'additional' purchase ;-) 


We have sometimes run into a problem where if the 
NAS fails, or the customers DSL router messes up and tries to login hundreds of 
times a minute we soon run out of available IP addresses in RADPOOL - upon 
inspection of RADPOOL it shows that the same user has dozens or more ip 
addresses allocated to them with a state of (1).

It would be good if there was some method of 
clearing these up - currently, we run a script which sets the state of all but 
the most receint allocation to (0) for any user with more than one entry in 
RADPOOL. (We don't allow simultaneous logins on our DSL 
service)

Has anyone else has similar problems and/or found a 
solution?

Regards, Brian.



  - Original Message - 
  From: 
  Hugh Irvine 

  To: Ayotunde Itayemi 
  Cc: [EMAIL PROTECTED] 
  Sent: Monday, August 19, 2002 11:48 
  PM
  Subject: Re: (RADIATOR) Re: 
  DefaultLeasePeriod
  Hello Tunde -By definition a customer with a 
  permanent connection would not use a dynamic address.You should 
  allocate such users static addresses 
instead.regardsHugh


(RADIATOR) radiator dies w/sql

2002-08-19 Thread Tony Bunce








We have been running radiator for a long time now and have
not had any problems, but have one issue



I have the conf file such that if our AuthBy SQL ignores the
request then it goes to AuthBy File. This way if the sql server dies
users can still authenticate on the flat file



We have never had problems with the sql server (MySql) but I
was trying to test the authby file by stopping the sql server. Radiator
looses its connection then dies w/o logging anything



Here is conf:



Trace 4



#Lower case

RewriteUsername tr/A-Z/a-z/



#Remove Spaces

RewriteUsername
s/\s+//g





ClientListSQL


DBSource DBI:Sybase:database=DB;server=SRV


DBUsername CUT


DBAuth CUT


GetClientQuery
select
NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERHOOK,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,FLAGS
from NASClients


#UseOldAscendPasswords

/ClientListSQL



SessionDatabase SQL

 DBSource dbi:mysql:radius:207.40.xxx.xx

 DBUsername
CUT

 DBAuth CUT

/SessionDatabase



Log SQL

 DBSource dbi:mysql:radius:207.40.xxx.xx

 DBUsername
CUT

 DBAuth CUT



 Table RADLOG

/Log

AuthLog SQL

 Identifier AuthLogMySql

 DBSource dbi:mysql:radius:207.40.xxx.xx

 DBUsername CUT

 DBAuth CUT

 Table AuthLog 

 FailureQuery
INSERT into AuthLog (SeverityLevel, Username, SubmitedPassword, Reason, Date)
VALUES (%0, '%U','%P',%1, '%Y-%m-%d %H:%M:%S')

 LogFailure 1

/AuthLog

Handler Request-Type=Access-Request

 RewriteUsername
s/^([^@]+).*/$1/



 AuthBy
SQL


Timeout 10


NoDefaultIfFound


DefaultSimultaneousUse 1


CaseInsensitivePasswords


RejectEmptyPassword




Identifier GOCsql


DefaultReply
Ascend-Shared-Profile-Enable=0,Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Routing=None,Ascend-Base-Channel-Count=1,Ascend-Minimum-Channels=1,Ascend-Maximum-Channels=1,Ascend-Assign-IP-Pool=1,Ascend-Multicast-Client=Multicast-Yes




DBSource DBI:Sybase:database=bill2;server=GO19


DBUsername CUT


DBAuth CUT




AuthSelect AuthSelect '%n'




AuthColumnDef
0, User-Password, check


AuthColumnDef 1, Framed-IP-Address, reply


AuthColumnDef 2, Framed-Netmask, reply


AuthColumnDef 3, GENERIC, reply


AuthColumnDef 4, GENERIC, check




AddToReplyIfNotExist Framed-Routing=None,Service-Type=Framed-User,Framed-Protocol=PPP

 /AuthBy
SQL

 AuthBy
FILE


NoDefaultIfFound


DefaultSimultaneousUse 2

 /AuthBy
FILE

 AuthLog AuthLogMySql

/Handler



And The Error Log:



Wed Aug 14 13:39:25 2002: ERR: do
failed for 'delete from RADONLINE where NASIDENTIFIER='207.40.122.227' and
NASPORT=020312': Lost connection to MySQL server during query

#THIS IS WHERE I RESTARTED IT b/c IT DIED

Wed Aug 14 13:40:44 2002: DEBUG:
Adding Clients from SQL database

Wed Aug 14 13:40:44 2002: DEBUG: Query
is: select NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOM



Wed Aug 14 13:40:44 2002: DEBUG:
Reading users file /etc/radiator/users

Wed Aug 14 13:40:44 2002: INFO: Server
started: Radiator 3.0 on rad1.go-concepts.com



Thanks for the help



Thanks,

Tony B, CCNA, Network+

Systems Administration

GO Concepts, Inc. / www.go-concepts.com

Are you on the GO yet?

What about those you know, are they on the GO?

513.934.2800

1.888.ON.GO.YET










(RADIATOR) radiator dies w/sql

2002-08-19 Thread Tony Bunce

We have been running radiator for a long time now and have not had any problems, but 
have one issue
 
I have the conf file such that if our AuthBy SQL ignores the request then it goes to 
AuthBy File.  This way if the sql server dies users can still authenticate on the flat 
file
 
We have never had problems with the sql server (MySql) but I was trying to test the 
authby file by stopping the sql server.  Radiator looses it's connection then dies w/o 
logging anything
 
Here is conf:
 
#Foreground
#LogStdout
LogDir  /var/log/radius
DbDir   /etc/radiator
DictionaryFile %D/dictionary
 
 
 
# it to 4 or 5 for debugging, or use the -trace flag to radiusd
Trace   4
 
#AuthPort 2900
#AcctPort 2901
 
#Lower case
RewriteUsername   tr/A-Z/a-z/
 
#Remove Spaces
RewriteUsername  s/\s+//g
 
 
#DateFormat '%Y-%M-%d %T'
 
ClientListSQL
    DBSource DBI:Sybase:database=bill2;server=GO19
    DBUsername CUT
    DBAuth CUT
    GetClientQuery select 
NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERHOOK,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,FLAGS
 from NASClients
    #UseOldAscendPasswords
/ClientListSQL
 
 
SessionDatabase SQL
    DBSource dbi:mysql:radius:207.40.xxx.xx
    DBUsername CUT
    DBAuth  CUT
/SessionDatabase
 
Log SQL
    DBSource dbi:mysql:radius:207.40.xxx.xx
    DBUsername CUT
    DBAuth  CUT
 
    Table RADLOG
/Log
 
AuthLog SQL
    Identifier AuthLogMySql
    DBSource dbi:mysql:radius:207.40.xxx.xx
    DBUsername CUT
    DBAuth  CUT
    Table AuthLog 
    FailureQuery INSERT into AuthLog (SeverityLevel, Username, SubmitedPassword, 
Reason, Date) VALUES (%0, '%U','%P',%1, '%Y-%m-%d %H:%M:%S')
    LogFailure 1
/AuthLog
 
 
 
Handler Request-Type=Access-Request
    RewriteUsername s/^([^@]+).*/$1/
    #PasswordLogFileName %L/password.log
 
    AuthBy SQL
    Timeout 10
    NoDefaultIfFound
    DefaultSimultaneousUse 1
    CaseInsensitivePasswords
    RejectEmptyPassword
 
    Identifier GOCsql
    DefaultReply 
Ascend-Shared-Profile-Enable=0,Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Routing=None,Ascend-Base-Channel-Count=1,Ascend-Minimum-Channels=1,Ascend-Maximum-Channels=1,Ascend-Assign-IP-Pool=1,Ascend-Multicast-Client=Multicast-Yes

 
    DBSource DBI:Sybase:database=bill2;server=GO19
    DBUsername CUT
    DBAuth CUT
 
    AuthSelect AuthSelect '%n'
 
    AuthColumnDef 0, User-Password, check
    AuthColumnDef 1, Framed-IP-Address, reply
    AuthColumnDef 2, Framed-Netmask, reply
    #AuthColumnDef 3, Ascend-Maximum-Channels, reply
    AuthColumnDef 3, GENERIC, reply
    AuthColumnDef 4, GENERIC, check
 
 
    #AddToReplyIfNotExist 
User-Service=Framed-User,Framed-Protocol=PPP,Framed-Routing=None,Ascend-Base-Channel-Count=1,Ascend-Minimum-Channels=1,Ascend-Maximum-Channels=1,Ascend-Assign-IP-Pool=1,Ascend-Multicast-Client=Multicast-Yes

    AddToReplyIfNotExist 
Framed-Routing=None,Service-Type=Framed-User,Framed-Protocol=PPP
    /AuthBy SQL
    AuthBy FILE
    NoDefaultIfFound
    DefaultSimultaneousUse 2
    /AuthBy FILE
    AuthLog AuthLogMySql
/Handler
 
 
Handler Request-Type=Accounting-Request
    AuthBy SQL
    DateFormat %Y-%m-%d %T
    Identifier MySQL
    DBSource dbi:mysql:radius:207.40.xxx.xx
    DBUsername CUT
    DBAuth  CUT 
 
 
    AuthSelect  
 
    AccountingTable Accounting%{Acct-Status-Type}
    #AccountingTable Accounting
    AcctColumnDef   Username,%U,formatted
    AcctColumnDef   TIME_STAMP,Timestamp,integer
    AcctColumnDef   AcctStatusType,Acct-Status-Type
    AcctColumnDef   SessionID,Acct-Session-Id
    AcctColumnDef   SessionTime,Acct-Session-Time,integer
    AcctColumnDef   DisconnectCause,Ascend-Disconnect-Cause,integer
    AcctColumnDef   ConnectProgress,Ascend-Connect-Progress,integer
    AcctColumnDef   NASIdentifier,NAS-Identifier
    AcctColumnDef   NASPort,NAS-Port,integer
    AcctColumnDef   ModemPort,Ascend-Modem-PortNo,integer
    AcctColumnDef   ModemSlot,Ascend-Modem-SlotNo,integer
    AcctColumnDef   IPAddress,Framed-IP-Address
    AcctColumnDef   XmitRate,Ascend-Xmit-Rate
 

(RADIATOR) proxy based on a prefix

2002-08-19 Thread Anura Abayaratne

Dear sirs,

We have radius proxy server running Radiator-2.18.4 on Solaris. I would 
like to know whether this server supports proxy based on a prefix. (eg. 
TEST/username@domain )

Thanks in advance
Anura

===
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) Accounting Handled

2002-08-19 Thread rcortez

Hi,



  Where can we put the accounting handled parameter is it on the 
authby clause? Can i have a sample config on how to implement it.



Ray

===
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.