Re: (RADIATOR) Keeping lines open

1999-05-05 Thread Karl Gaissmaier

Hi,

ryanm schrieb:
 
 Has anyone implemented a way to keep 2/4/6 phone lines open by
 booting the user who has been logged on the longest?? Where we
 have 200 modems in a pool the ppl that have been on the longest
 are usually the ppl who are trying to stay on 24/7. We want to
 keep 2-4 phone lines open so a user will never get a busy signal.
 
 Also does anyone know if it is possible to disconnect users who
 are pinging servers to stay online?? I want to boot users who
 are not doing anything for hours on end trying to stay connected
 or whatever.
 

It depends on the NAS Box. With Ascend you can do this.
What box do you have?

Regards
Charly
-- 
Karl Gaissmaier  Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED]  Network Administration
Tel/Fax: ++49 731 50 22499/22471
pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html

===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) Timestamp

1999-05-05 Thread Mike McCauley

Hi Anton,

The timestamp figure is in UTC, ie seconds since midnight Jan 1 1970 UTC.

The "May 5 17:45:02 1999" string is generated using localtime, and therefore
takes into account your local timezone. For example, when I convert 925886702
to localtime here, I get:

Wed May  5 16:45:02 Australia/Victoria 1999

which is 10 hours ahead of the UTC version you give (as expected for my
timezone).

I suspect that your timezone setting on the host machine is not correct,
irrespective of whether its showing tghe correct time. Else, the timezone
setting that Radiator process is running as is different to the one where you
are checking where the time is right (cant be more precise, as you dont mention
what sort of host machine you are running one)

Hope that helps.

Cheers.

On May 5,  5:56pm, Anton Sparrius wrote:
 Subject: (RADIATOR) Timestamp

 [ Attachment (text/plain): 986 bytes
   Character set: Windows-1252
   plain text ]
-- End of excerpt from Anton Sparrius


Ok, It's late and I am tired, so I'll ask instead of spending ages trying to
figure it out for my self.

In the details log file, a start/stop request has this entry :

May 5 17:45:02 1999
...
TimeStamp 925886702

According to my calculations, the timestamp works out to be 05-May-99
6:45:02 AM

I think I used to know why, but I can't remember what the reason was, but
timestamp was always 10 hours wrong.  Ie, using GMT time rather than Melb
time.  However, it's now an extra hour out, ie 11 hours behind.

The time on the NAS's and on the PC running Radiator are correct.

Any ideas???

Regards,

Anton Sparrius
Chief Operations Officer

-- 
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, etc etc on Unix, Win95/8, 
NT, Rhapsody
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) Realm authentication problems

1999-05-05 Thread Felix Izquierdo

Mike McCauley wrote:
  Mike, in relation with this issue, is it posible to strip the realm only
  for authentication but not for accounting?
 
 No, not easily.
 
 It might be possible to set up one Handler that does accounting and does not
 strip the realm, and a differnt Handler than does strip the realm:
 

Is posible ( in a future version ) to permit the use of the
RewriteUsername sentence in the AuthBy context? It seems a solution...

Félix
__
DATAGRAMA SERVICIOS INTERNET
C/ Acer 30Tlf: +34 3 223 00 98
08038 BARCELONA ( Spain ) Fax: +34 3 223 12 66
mailto:[EMAIL PROTECTED] http://www.datagrama.net
__

ÿ
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) Blocking based on Caller ID

1999-05-05 Thread Brian


I have some NAS boxes that are in City A, and some NAS boxes that are in
City B.  City A is long distance from City B.  I do not want users to be
able to dial from City A to City B.

What is the best way to handle this?  I don't want to put something on
each "user" in radius.  I would rather do something with clients/realms,
so that if a call comes into a CLIENT that is in City B, and it sees
caller id from City a, it drops the call.

Tell me if this sounds like the way to do it:

1. Assign clients of city A to realm "CityA".
2. Assign clients of city B to realm "CityB".
3. Make a DefaultCheck for Realm CityA to check the areacode of the call,
using regexp.
4. Make a Defaultcheck for Realm CityB to check the areacode of the call,
using regexp.

Is their a better way?


-
Brian Feeny (BF304) [EMAIL PROTECTED]   
318-222-2638 x 109  http://www.shreve.net/~signal  
Network Administrator   ShreveNet Inc. (ASN 11881)


===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) Blocking based on Caller ID

1999-05-05 Thread Stuart Henderson

 Is their a better way?

If you can implement caller id-based filtering in the nas that
will be better as it will avoid toll calls for your users to try
to get authenticated only to find it failing. (I think many
people would just try again, and again, if it comes back saying
'bad password' or similar).

Cheers
Stuart

===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) Blocking based on Caller ID

1999-05-05 Thread Mike McCauley

On May 5,  5:45pm, Stuart Henderson wrote:
 Subject: Re: (RADIATOR) Blocking based on Caller ID
  Is their a better way?

 If you can implement caller id-based filtering in the nas that
 will be better as it will avoid toll calls for your users to try
 to get authenticated only to find it failing. (I think many
 people would just try again, and again, if it comes back saying
 'bad password' or similar).

That sounds like good advice.

If Brian did want to implement in Radiator, its probably best to use Handlers
rather than Realms. By checking a combination of NAS-IP-Address and
Calling-Station-Id, you should be able to discriminate between the ones you are
prepared to handle

Handler NAS-Ip-Address=10.11.12.13,Calling-Station-Id=/^403/
# This will handle calls into that NAS from numbers that start with 403
/Handler

Handler NAS-Ip-Address=11.11.12.13,Calling-Station-Id=/^201/
# This will handle calls into that NAS from numbers that start with 201
/Handler

Handler
# This will handle all the "illegal" combinations.
# without an AuthBy it will always reject
/Handler

Hope that helps.

Cheers.

-- 
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, etc etc on Unix, Win95/8, 
NT, Rhapsody
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.