(RADIATOR) SessionDatabase Problem
Hugh Irvine
hugh at open.com.au
Fri Jan 25 19:28:59 CST 2002
Hello Julian -
The entries in the session database are maintained by the accounting records
sent by the NAS once the session starts. If you are not receiving accounting
records, you will not see any entries in the RADONLINE table.
regards
Hugh
On Sat, 26 Jan 2002 03:51, Julian Rose wrote:
> Hi All,
>
> I am having problems with getting the session database function to work
> correctly,
>
> When I issue a request to the server, I see the server try to run the
> delete query, but not the add or count queries.
>
> Is something wrong here, or do I not understand the function properly ;)
>
> Best regards.. Julian.
>
> ----debug----
> Attributes:
> NAS-IP-Address = 195.54.226.39
> NAS-Port = 38
> NAS-Port-Type = Async
> User-Name = "test"
> Called-Station-Id = "408"
> Calling-Station-Id = "2074281900"
> User-Password =
> "<210>t<233>:<243>d<31><25>n<190><201><146><194>fz<141>"
> Service-Type = Framed-User
> Framed-Protocol = PPP
>
> Fri Jan 25 16:13:41 2002: DEBUG: Handling request with Handler
> 'Realm=atlas.co.uk'
> Fri Jan 25 16:13:41 2002: DEBUG: rad-a Deleting session for test,
> 195.54.226.39, 38
> Fri Jan 25 16:13:41 2002: DEBUG: do query is: delete from RADONLINE where
> NASIDENTIFIER='195.54.226.39' and NASPORT=038
>
> Fri Jan 25 16:13:41 2002: DEBUG: Handling with Radius::AuthSQL
> Fri Jan 25 16:13:41 2002: DEBUG: Handling with Radius::AuthSQL:
> Fri Jan 25 16:13:41 2002: DEBUG: Query is: select s.PASSWORD, r.ATTR1,
> r.ATTR2, s.ATTR1, s.ATTR2, s.ATTR3, s.ATTR4 from STANDARD s, REALMS r where
> s.REALM = r.REALM AND s.USERNAME="test" and s.ACTIVE="Y"
>
> Fri Jan 25 16:13:41 2002: DEBUG: Radius::AuthSQL looks for match with
> test at atlas.co.uk
> Fri Jan 25 16:13:41 2002: DEBUG: Radius::AuthSQL ACCEPT:
> Fri Jan 25 16:13:41 2002: DEBUG: Access accepted for test at atlas.co.uk
> Fri Jan 25 16:13:41 2002: DEBUG: do query is: insert into AUTHLOG values
> ('1011975221', 'test', 'atlas.co.uk', '195.54.226.39', 'OK', '')
>
> Fri Jan 25 16:13:41 2002: DEBUG: Packet dump:
> *** Sending to 195.54.226.39 port 1645 ....
>
> Packet length = 44
> 02 0f 00 2c 10 13 24 a6 08 dd 7c 3c d9 91 02 a4
> 78 04 e3 09 08 06 c3 36 e9 01 06 06 00 00 00 02
> 0d 06 00 00 00 01 07 06 00 00 00 01
> Code: Access-Accept
> Identifier: 15
> Authentic:
> <144><5><13><28><160><231><211><138>i<146><153><254><177><209>\e
> Attributes:
> Framed-IP-Address = 195.54.233.1
> User-Service = 2
> Framed-Compression = Van-Jacobsen-TCP-IP
> Framed-Protocol = PPP
> ----/debug----
>
> ----config----
> <Realm atlas.co.uk>
> <AuthBy SQL>
> DBSource dbi:mysql:radius
> DBUsername ###From owner-radiator at open.com.au Fri Jan 25 18:18:19 2002
Received: (from majordomo at localhost)
by server1.open.com.au (8.11.0/8.11.0) id g0Q0IJO24361
for radiatorzz-list; Fri, 25 Jan 2002 18:18:19 -0600
X-Authentication-Warning: server1.open.com.au: majordomo set sender to owner-radiator at open.com.au using -f
Received: from entoo.connect.com.au (entoo.connect.com.au [192.189.54.8])
by server1.open.com.au (8.11.0/8.11.0) with ESMTP id g0Q0II324357;
Fri, 25 Jan 2002 18:18:18 -0600
Received: from there (acc16-ppp6.mel.dialup.connect.net.au [210.10.135.6])
by entoo.connect.com.au (Postfix) with SMTP
id DDBE4E3332; Sat, 26 Jan 2002 12:48:31 +1100 (EST)
Content-Type: text/plain;
charset="iso-8859-1"
From: Hugh Irvine <hugh at open.com.au>
Reply-To: hugh at open.com.au
Organization: Open System Consultants
To: terry at ccis.net, radiator at open.com.au
Subject: IMPORTANT - Re: (RADIATOR) Surprises in dictionary when upgrading Radiator
Date: Sat, 26 Jan 2002 12:10:07 +1100
X-Mailer: KMail [version 1.3.1]
References: <OF6E932002.D7FC9266-ON85256B4C.006B16C4 at chesco.com>
In-Reply-To: <OF6E932002.D7FC9266-ON85256B4C.006B16C4 at chesco.com>
Cc: mikem at open.com.au
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20020126014831.DDBE4E3332 at entoo.connect.com.au>
Sender: owner-radiator at open.com.au
Precedence: bulk
List-Id: <radiator.list-id.open.com.au>
Hello Terry, Hello Everyone -
There is nothing arbitrary about radius dictionary definitions - all of the
"standard" attributes are defined by the Radius RFC's, and all of the
"vendor-specific" attributes are defined by the respective vendors.
The problems occur because the RFC's are constantly being revised, and new
attributes continue to be defined. Vendors as well continue to add
functionality to their software and to add their own vendor-specifics as a
consequence.
We try as much as possible to include the new attribute definitions in the
dictionaries we distribute and we appreciate people sending us the new ones
as they appear (because the vendors don't).
Note however that one single "standard" dictionary (one size fits all) is
never going to happen, because everyone has different hardware/software
combinations. It is therefore important that you understand what requirements
you have and that you tailor your dictionary to suit. My recommendation
always is to start with the standard Radiator dictionary and add/delete
entries as required.
On a technical note, the dictionary is used to construct two tables inside
Radiator at startup time. The first table is the correspondence between the
binary attribute number and the corresponding human-readable string
(attribute name), and the second table is the correspondence between the
string and the binary attribute number.
Unsurprisingly, the first table is used when Radiator receives a packet to
unpack the encoded binary into the corresponding attribute names. And the
second table is used to pack the attribute names (and values) into the binary
packet ready for transmission.
BTW - "EAP" as mentioned below is the "Extensible Authentication Protocol"
which has recently been added in the Radius RFC's and therefore there are
some new attribute definitions required.
Hope that helps.
regards
Hugh
On Sat, 26 Jan 2002 06:35, terry at ccis.net wrote:
> When I upgraded to Radiator 1.86, I started getting a new error,
>
> Fri Jan 25 11:45:00 2002: ERR: Attribute number 79 is not defined in
> your dictionary
>
> which is odd, as I wasn't getting that error with the old version (same
> dictionary). I found an attribute to quiet it down,
>
> ATTRIBUTE EAP-Message 79 data
>
> but it's kind of arbitrary. Anybody know what it is? The RAS this services
> are a mix of Cisco 5300s and Max 6096s
>
> Thanks,
> Terry
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable R####
> DBAuth #######
> AuthSelect \
> select s.PASSWORD, r.ATTR1, r.ATTR2, s.ATTR1, \
> s.ATTR2, s.ATTR3, s.ATTR4 from STANDARD s, REALMS r \
> where s.REALM = r.REALM AND s.USERNAME="%U" and
> s.ACTIVE="Y" AuthColumnDef 0, User-Password, check
> AuthColumnDef 1, User-Service, reply
> AuthColumnDef 2, Framed-Compression, reply
> AuthColumnDef 3, Framed-Protocol, reply
> AuthColumnDef 4, Framed-IP-Address, reply
> AuthColumnDef 5, cisco-avpair, reply
> AuthColumnDef 6, Idle-Timeout, reply
> # Accounting Logs
> AccountingTable ACCOUNTING
> AcctColumnDef USERNAME,User-Name
> AcctColumnDef TIME_STAMP,Timestamp,integer
> AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type
> AcctColumnDef ACCTDELAYTIME,Acct-Delay-Time,integer
> AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets,integer
> AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
> AcctColumnDef ACCTSESSIONID,Acct-Session-Id
> AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time,integer
> AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause
> AcctColumnDef NASIDENTIFIER,NAS-Identifier
> AcctColumnDef NASPORT,NAS-Port,integer
> AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address
> AcctFailedLogFileName %L/missedaccounting
> </AuthBy>
> AuthLog sqllog
> </Realm>
> <SessionDatabase SQL>
> DBSource dbi:mysql:radius
> DBUsername #######
> DBAuth #######
> </SessionDatabase>
> ----/config---
>
>
> _____________________________________________________________________
> This message has been checked for all known viruses by Atlas Internet
> Powered by MessageLabs - http://www.atlas.net.uk
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
ADIUS 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list