RE: (RADIATOR) Ascend SNMP Problems
Hugh, Returning to the Logfile: Mon Aug 27 11:53:11 2001: DEBUG: Checking if user is still online: AscendSNMP, lydia, 207.65.70.7, 842, 326199869 Mon Aug 27 11:53:11 2001: DEBUG: Running command `/usr/bin/snmpget 207.65.70.7 community .iso.org.dod.internet.private.enterprises.326199869 Mon Aug 27 11:53:11 2001: NOTICE: sessiondb Session for lydia at 207.65.70.7:842 has gone away Mon Aug 27 11:53:11 2001: DEBUG: sessiondb Deleting session for lydia, 207.65.70.7, 842 Mon Aug 27 11:53:11 2001: DEBUG: do query is: delete from RADONLINE where USERNAME='[EMAIL PROTECTED]' and NASIDENTIFIER='207.65.70.7' As you can see the function AscendSNMP gets called with the re-written username. If this is incorrect Please enlighten me why the log files show the wrong message. :) Leon -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 29, 2001 7:22 PM To: Leon Oosterwijk; '[EMAIL PROTECTED]' Subject: Re: (RADIATOR) Ascend SNMP Problems Hello Leon - Radiator will always use the original username as received in the request for checking the NAS. However I note in your configuration below that you should probably (correct me if I'm wrong) change the CountQuery to count the rewritten usernames: CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from \ RADONLINE where RRUSERNAME='%U' hth Hugh === 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) Ascend SNMP Problems
Hello Leon - Could you please send me the complete configuration file (no secrets)? thanks Hugh On Friday 31 August 2001 00:23, Leon Oosterwijk wrote: Hugh, Returning to the Logfile: Mon Aug 27 11:53:11 2001: DEBUG: Checking if user is still online: AscendSNMP, lydia, 207.65.70.7, 842, 326199869 Mon Aug 27 11:53:11 2001: DEBUG: Running command `/usr/bin/snmpget 207.65.70.7 community .iso.org.dod.internet.private.enterprises.326199869 Mon Aug 27 11:53:11 2001: NOTICE: sessiondb Session for lydia at 207.65.70.7:842 has gone away Mon Aug 27 11:53:11 2001: DEBUG: sessiondb Deleting session for lydia, 207.65.70.7, 842 Mon Aug 27 11:53:11 2001: DEBUG: do query is: delete from RADONLINE where USERNAME='[EMAIL PROTECTED]' and NASIDENTIFIER='207.65.70.7' As you can see the function AscendSNMP gets called with the re-written username. If this is incorrect Please enlighten me why the log files show the wrong message. :) Leon -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 29, 2001 7:22 PM To: Leon Oosterwijk; '[EMAIL PROTECTED]' Subject: Re: (RADIATOR) Ascend SNMP Problems Hello Leon - Radiator will always use the original username as received in the request for checking the NAS. However I note in your configuration below that you should probably (correct me if I'm wrong) change the CountQuery to count the rewritten usernames: CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from \ RADONLINE where RRUSERNAME='%U' hth Hugh === 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) Ascend SNMP Problems
Hugh,
Please help me in trying to setup the SNMP Pull with the non-rewritten
username. I've altered the config for my session db to store both versions
of the username. Following is the session Database as it is defined in our
configuration. Where do I change the behaviour of RADIATOR to use the
non-rewritten username for NAS-SNMP checks?
Leon
#***
#***
# SESSIONS Database holds the sessions for all the users
# /usr/local/bin/Radius-Session-DBCheck.pl removes stale entries
#***
#***
SessionDatabase SQL
Identifier sessiondb
DBSourcedbi:mysql:radadmin:host=host.isdn.net
DBUsername username
DBAuth password
AddQuery insert into RADONLINE (RRUSERNAME, USERNAME,
NASIDENTIFIER, NASPORT, \
ACCTSESSIONID, FRAMEDIPADDRESS, NASPORTTYPE, \
SERVICETYPE, DNIS, CALLINGSTATIONID, TIME_STAMP)
values ('%U', '%u', '%N', %{NAS-Port}, \
'%{Acct-Session-Id}',
'%{Framed-IP-Address}', '%{Port-Type}', '%{Framed-Protocol}', \
'%{Called-Station-Id}', '%{Calling-Station-Id}',
'%{Timestamp}' )
DeleteQuery delete from RADONLINE where USERNAME='%u' and \
NASIDENTIFIER='%N' and NASPORT='%{NAS-Port}'
ClearNasQuery delete from RADONLINE where NASIDENTIFIER='%N'
CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from \
RADONLINE where USERNAME='%u'
# The OLD query:
#select nasid, slotitem, sessionid from ses4web where
username='%u'
/SessionDatabase SQL
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 28, 2001 6:50 PM
To: Leon Oosterwijk; '[EMAIL PROTECTED]'
Subject: Re: (RADIATOR) Ascend SNMP Problems
Hello Leon -
You don't show the session database that you are using, but the problem is
because you are doing a RewriteUsername and the rewritten username is being
used to check against the NAS (which of course won't work).
The usual way to deal with this problem is to use an SQL session database
and
store both the original username and the rewritten username therein with
your
own queries. That way you can use the rewritten username for simultaneous
use
limit checking, and the original username for checking with the NAS.
regards
Hugh
===
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) Ascend SNMP Problems
Colin,
The issue at hand is about the fact that the username on the NAS is not the
same that the RADIUS server compares it against.
Leon
-Original Message-
From: Colin D. Easton [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 29, 2001 10:58 AM
To: 'Leon Oosterwijk'
Subject: RE: (RADIATOR) Ascend SNMP Problems
In my experience it's always good to set it at twice what it should be.
For regular users set to 2 and for isdn etc set to 4. This way most
race conditions may be avoided. It's not absolute nor is it perfect but
it works.
C.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Leon Oosterwijk
Sent: Wednesday, August 29, 2001 9:47 AM
To: '[EMAIL PROTECTED]'
Subject: RE: (RADIATOR) Ascend SNMP Problems
Hugh,
Please help me in trying to setup the SNMP Pull with the non-rewritten
username. I've altered the config for my session db to store both
versions
of the username. Following is the session Database as it is defined in
our
configuration. Where do I change the behaviour of RADIATOR to use the
non-rewritten username for NAS-SNMP checks?
Leon
#***
#***
# SESSIONS Database holds the sessions for all the users
# /usr/local/bin/Radius-Session-DBCheck.pl removes stale entries
#***
#***
SessionDatabase SQL
Identifier sessiondb
DBSourcedbi:mysql:radadmin:host=host.isdn.net
DBUsername username
DBAuth password
AddQuery insert into RADONLINE (RRUSERNAME, USERNAME,
NASIDENTIFIER, NASPORT, \
ACCTSESSIONID, FRAMEDIPADDRESS, NASPORTTYPE, \
SERVICETYPE, DNIS, CALLINGSTATIONID, TIME_STAMP)
values ('%U', '%u', '%N', %{NAS-Port}, \
'%{Acct-Session-Id}',
'%{Framed-IP-Address}', '%{Port-Type}', '%{Framed-Protocol}', \
'%{Called-Station-Id}', '%{Calling-Station-Id}',
'%{Timestamp}' )
DeleteQuery delete from RADONLINE where USERNAME='%u' and \
NASIDENTIFIER='%N' and NASPORT='%{NAS-Port}'
ClearNasQuery delete from RADONLINE where NASIDENTIFIER='%N'
CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from \
RADONLINE where USERNAME='%u'
# The OLD query:
#select nasid, slotitem, sessionid from ses4web where
username='%u'
/SessionDatabase SQL
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 28, 2001 6:50 PM
To: Leon Oosterwijk; '[EMAIL PROTECTED]'
Subject: Re: (RADIATOR) Ascend SNMP Problems
Hello Leon -
You don't show the session database that you are using, but the problem
is
because you are doing a RewriteUsername and the rewritten username is
being
used to check against the NAS (which of course won't work).
The usual way to deal with this problem is to use an SQL session
database
and
store both the original username and the rewritten username therein with
your
own queries. That way you can use the rewritten username for
simultaneous
use
limit checking, and the original username for checking with the NAS.
regards
Hugh
===
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) Ascend SNMP Problems
Hello Leon -
Radiator will always use the original username as received in the request for
checking the NAS.
However I note in your configuration below that you should probably (correct
me if I'm wrong) change the CountQuery to count the rewritten usernames:
CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from \
RADONLINE where RRUSERNAME='%U'
hth
Hugh
On Wednesday 29 August 2001 23:46, Leon Oosterwijk wrote:
Hugh,
Please help me in trying to setup the SNMP Pull with the non-rewritten
username. I've altered the config for my session db to store both versions
of the username. Following is the session Database as it is defined in our
configuration. Where do I change the behaviour of RADIATOR to use the
non-rewritten username for NAS-SNMP checks?
Leon
#***
#***
# SESSIONS Database holds the sessions for all the users
# /usr/local/bin/Radius-Session-DBCheck.pl removes stale entries
#***
#***
SessionDatabase SQL
Identifier sessiondb
DBSourcedbi:mysql:radadmin:host=host.isdn.net
DBUsername username
DBAuth password
AddQuery insert into RADONLINE (RRUSERNAME, USERNAME,
NASIDENTIFIER, NASPORT, \
ACCTSESSIONID, FRAMEDIPADDRESS, NASPORTTYPE, \
SERVICETYPE, DNIS, CALLINGSTATIONID, TIME_STAMP)
values ('%U', '%u', '%N', %{NAS-Port}, \
'%{Acct-Session-Id}',
'%{Framed-IP-Address}', '%{Port-Type}', '%{Framed-Protocol}', \
'%{Called-Station-Id}', '%{Calling-Station-Id}',
'%{Timestamp}' )
DeleteQuery delete from RADONLINE where USERNAME='%u' and \
NASIDENTIFIER='%N' and NASPORT='%{NAS-Port}'
ClearNasQuery delete from RADONLINE where NASIDENTIFIER='%N'
CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from \
RADONLINE where USERNAME='%u'
# The OLD query:
#select nasid, slotitem, sessionid from ses4web where
username='%u'
/SessionDatabase SQL
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 28, 2001 6:50 PM
To: Leon Oosterwijk; '[EMAIL PROTECTED]'
Subject: Re: (RADIATOR) Ascend SNMP Problems
Hello Leon -
You don't show the session database that you are using, but the problem is
because you are doing a RewriteUsername and the rewritten username is being
used to check against the NAS (which of course won't work).
The usual way to deal with this problem is to use an SQL session database
and
store both the original username and the rewritten username therein with
your
own queries. That way you can use the rewritten username for simultaneous
use
limit checking, and the original username for checking with the NAS.
regards
Hugh
===
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) Ascend SNMP Problems
Hello Leon - You don't show the session database that you are using, but the problem is because you are doing a RewriteUsername and the rewritten username is being used to check against the NAS (which of course won't work). The usual way to deal with this problem is to use an SQL session database and store both the original username and the rewritten username therein with your own queries. That way you can use the rewritten username for simultaneous use limit checking, and the original username for checking with the NAS. regards Hugh On Wednesday 29 August 2001 01:18, Leon Oosterwijk wrote: Hugh/Mike, I've got a problem with the DefaulSimultaneousUse. This does not seem to work for my realm-based customers. Below is a trace level 4 of the different steps for checking the simutaneous use. As you can see it checks with the Ascend NAS using AscendSNMP. But the USERNAME passed is lydia. Not [EMAIL PROTECTED]. Hence there is never match and Radiator thinks that the session has gone away. This however is not true. If the AscendSNMP would check agains [EMAIL PROTECTED] it would notice that this username and the username in the MIB match and deny access. Mon Aug 27 11:53:11 2001: DEBUG: Checking if user is still online: AscendSNMP, lydia, 207.65.70.7, 842, 326199869 Mon Aug 27 11:53:11 2001: DEBUG: Running command `/usr/bin/snmpget 207.65.70.7 community .iso.org.dod.internet.private.enterprises.326199869 Mon Aug 27 11:53:11 2001: NOTICE: sessiondb Session for lydia at 207.65.70.7:842 has gone away Mon Aug 27 11:53:11 2001: DEBUG: sessiondb Deleting session for lydia, 207.65.70.7, 842 Mon Aug 27 11:53:11 2001: DEBUG: do query is: delete from RADONLINE where USERNAME='[EMAIL PROTECTED]' and NASIDENTIFIER='207.65.70.7' I've done a little bit of poking around the code to try and find out where the problem lies. However the code is a little bit dense for me. :) Sincerely, Leon Oosterwijk The part of the config file that is relevant to cora.net: === # NetServices - cora.net #*** Handler Realm=cora.net # MaxSessions 1 RewriteUsername s/^([^@]+).*/$1/ AuthBy SQL DBSourcedbi:mysql:NETSERVICES:host=216.153.4.28 DBUsername root DBAuth shit AuthSelect select password, ip_address, netmask, port_limit, idle_timeout, max_connect_time from Dialup where user$ AuthColumnDef 0, User-Password, check AuthColumnDef 1, Framed-IP-Address, reply AuthColumnDef 2, Framed-IP-Netmask, reply AuthColumnDef 3, Ascend-Maximum-Channels, reply AuthColumnDef 4, Ascend-Idle-Limit, reply AuthColumnDef 5, Ascend-Maximum-Call-Duration, reply DefaultSimultaneousUse 1 PrependToReply Ascend-Assign-IP-Pool = 12 # PrependToReply Ascend-Idle-Limit = 1800 StripFromReply Proxy-State StripFromReply Filter-Id StripFromReply Framed-Routing StripFromReply Ascend-Idle-Limit AddToReply Ascend-Idle-Limit = 1800 AddToReplyIfNotExist Service-Type = Framed, Framed-Protocol = PPP, \ Ascend-Maximum-Call-Duration = 180, Ascend-Maximum-Channels = 2 #AddToReplyIfNotExist Framed-Routing = None #AddToReplyIfNotExist Service-Type = Framed #AddToReplyIfNotExist Framed-Protocol = PPP #AddToReplyIfNotExist Ascend-Idle-Limit = 1800 #AddToReplyIfNotExist Ascend-Maximum-Call-Duration = 180 #AddToReplyIfNotExist Ascend-Maximum-Channels = 2 /AuthBy /Handler === === 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.
