Re: (RADIATOR) Event-Timestamp patch
--On Thursday, October 24, 2002 10:55:45 PM +1000 Hugh Irvine
<[EMAIL PROTECTED]> wrote:
Hello Jerome -
I think the correct answer would be to have different processing for
"Timestamp" and "Event-Timestamp", not to override what is currently done
by Radiator with "Timestamp", given that they are different ideas of what
"time" is.
In any case, if "Event-Timestamp" is present in a request, then it will
not interfere with Radiator's own "Timestamp". And it is available as the
special character %{Event-Timestamp}, exactly like %{Timestamp} is, so
you needn't write a hook anyway (as mentioned in my previous mail).
OK, I agree with that.
--
Jerome Fleury
===
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) Acct-Session-Id Error
Greetings. I'm getting the following error in my radius log: Thu Oct 24 11:21:38 2002: ERR: There is no value named Á-#×ز for attribute Acct-Session-Id. Using 0. Thu Oct 24 11:23:13 2002: ERR: There is no value named Á-#×Ôo for attribute Acct-Session-Id. Using 0. Thu Oct 24 11:23:21 2002: ERR: There is no value named Á-#×× for attribute Acct-Session-Id. Using 0. Thu Oct 24 11:23:24 2002: ERR: There is no value named Á-#×ص for attribute Acct-Session-Id. Using 0. Thu Oct 24 11:23:26 2002: ERR: There is no value named Á-#××i for attribute Acct-Session-Id. Using 0. The value changes each time, so I think maybe the problem might just be that our NAS is thinking Acct-Session-Id is of a different type than what Radiator is expecting. The NAS is a CVX 600. I'm running Radiator-3.3. Here is what I believe to be the most relevant configuration snippet: Identifier SimpleSQLAuth DBSourcedbi:Sybase:x DBUsername x DBAuth x # use the LoginLimit from the emerald database #AuthSelect ,sa.LoginLimit #AuthColumnDef 0,Simultaneous-Use,check AccountingTable Calls AcctColumnDef UserName,User-Name AcctColumnDef CallDate,Timestamp,integer-date AcctColumnDef AcctStatusType,Acct-Status-Type,integer AcctColumnDef AcctDelayTime,Acct-Delay-Time,integer AcctColumnDef AcctInputOctets,Acct-Input-Octets,integer AcctColumnDef AcctOutputOctets,Acct-Output-Octets,integer #AcctColumnDef AcctSessionId,Acct-Session-Id,integer AcctColumnDef AcctSessionTime,Acct-Session-Time,integer AcctColumnDef AcctTerminateCause,Acct-Terminate-Cause,integer AcctColumnDef FramedAddress,Framed-IP-Address AcctColumnDef FramedProtocol,Framed-Protocol,integer AcctColumnDef NASIdentifier,NAS-Identifier AcctColumnDef NASIdentifier,NAS-IP-Address AcctColumnDef NASPort,NAS-Port,integer # Check the Platypus database for everyone who has nowhere else to go # remove everything after the @, including the @ RewriteUsername s/^([^@]+).*/$1/ PasswordLogFileName%L/password.log AuthBy SimpleSQLAuth # AuthByPolicy ContinueAlways # AuthBy Acct-only-Database # AuthBy Auth-only-Database We have many more Realms, but they are all in the same format as this (and we log to a local database, but proxy radius to customers): PasswordLogFileName%L/password.log AuthByPolicy ContinueAlways AuthBy Acct-only-Database AuthBy xRadius Identifier Acct-only-Database AuthSelect DBSourcedbi:Sybase: DBUsername x DBAuth x AccountingTable Calls AcctColumnDef UserName,User-Name AcctColumnDef CallDate,Timestamp,integer-date AcctColumnDef AcctStatusType,Acct-Status-Type,integer AcctColumnDef AcctDelayTime,Acct-Delay-Time,integer AcctColumnDef AcctInputOctets,Acct-Input-Octets,integer AcctColumnDef AcctOutputOctets,Acct-Output-Octets,integer AcctColumnDef AcctSessionId,Acct-Session-Id,string AcctColumnDef AcctSessionTime,Acct-Session-Time,integer AcctColumnDef AcctTerminateCause,Acct-Terminate-Cause,integer AcctColumnDef FramedAddress,Framed-IP-Address AcctColumnDef FramedProtocol,Framed-Protocol,integer AcctColumnDef NASIdentifier,NAS-Identifier AcctColumnDef NASIdentifier,NAS-IP-Address AcctColumnDef NASPort,NAS-Port,integer Thanks for any ideas! --Doug === 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) Event-Timestamp patch
Hello Jerome -
I think the correct answer would be to have different processing for
"Timestamp" and "Event-Timestamp", not to override what is currently
done by Radiator with "Timestamp", given that they are different ideas
of what "time" is.
In any case, if "Event-Timestamp" is present in a request, then it will
not interfere with Radiator's own "Timestamp". And it is available as
the special character %{Event-Timestamp}, exactly like %{Timestamp} is,
so you needn't write a hook anyway (as mentioned in my previous mail).
regards
Hugh
On Thursday, October 24, 2002, at 09:47 PM, Jerome Fleury wrote:
--On Thursday, October 24, 2002 04:11:44 PM +1000 Hugh Irvine
<[EMAIL PROTECTED]> wrote:
Hi Mike -
I don't agree with changing Radiator's Timestamp.
If there is an Event-Timestamp in a request and someone wants to use
it,
it is simple enough to use special characters (%{Event-Timestamp}),
and/or write a hook to make whatever changes are wanted/needed on a
local
basis.
I understand your point of view about that patch. But keep in mind
that Event-Timestamp is a standard Radius Attribute defined in RFC2869
(Radius Extensions), that should be implemented by more and more
devices as time goes on.
This attribute has been added so that the server should not calculate
timestamps but let network devices do this job.
Therefore Radiator should allow the use of this attribute (if it
exists) in a more friendly way than having to write a hook.
--
Jerome Fleury
NB: I am travelling this week, so there may be delays in our
correspondence.
--
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) Event-Timestamp patch
--On Thursday, October 24, 2002 04:11:44 PM +1000 Hugh Irvine
<[EMAIL PROTECTED]> wrote:
Hi Mike -
I don't agree with changing Radiator's Timestamp.
If there is an Event-Timestamp in a request and someone wants to use it,
it is simple enough to use special characters (%{Event-Timestamp}),
and/or write a hook to make whatever changes are wanted/needed on a local
basis.
I understand your point of view about that patch. But keep in mind that
Event-Timestamp is a standard Radius Attribute defined in RFC2869 (Radius
Extensions), that should be implemented by more and more devices as time
goes on.
This attribute has been added so that the server should not calculate
timestamps but let network devices do this job.
Therefore Radiator should allow the use of this attribute (if it exists) in
a more friendly way than having to write a hook.
--
Jerome Fleury
===
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) ServiceAttrQuery parameter ignored
I use the auth and UserAttrQuery and ServiceAttrQuery
(Service profiles) parameters
for check and reply items. UserAttrQuery works fine but the radius server
seems to ignore the ServiceAttrQuery parameter. I don't see anything
specifically relating to the configuration of ServiceAttrQuery in the
documentation except what is under 6.31.4. I have attached my radius config
file and trace output. I have received the 3.3.1 Radiator patch for
AuthRADMIN.pm and there is still no difference.
Bret Zarkiewicz
Engineer
UTStarcom, Inc.
phone: 732.516.7581
email: [EMAIL PROTECTED]
web: http://www.utstar.com
Wed Oct 23 12:17:54 2002: DEBUG: Packet dump:
*** Received from 192.168.16.204 port 1025
Packet length = 78
01 aa 00 4e f4 7c 3e 75 77 39 e5 3c bf 7a 45 43
df 52 58 76 01 07 6c 6f 67 69 6e 03 13 02 c2 63
2e 63 b2 ae 1c 8c fb 24 4c d6 20 7e a7 f5 04 06
c0 a8 10 cc 05 06 00 00 00 0d 1a 14 00 00 17 3c
11 0e 61 74 6d 20 31 2f 30 3a 30 2e 33 32
Code: Access-Request
Identifier: 170
Authentic: <244>|>uw9<229><<191>zEC<223>RXv
Attributes:
User-Name = "login"
CHAP-Password = <2><194>c.c<178><174><28><140><251>$L<214> ~<167><245>
NAS-IP-Address = 192.168.16.204
NAS-Port = 13
Issanni-Interface-Name = "atm 1/0:0.32"
Wed Oct 23 12:17:54 2002: DEBUG: Handling request with Handler 'Realm=DEFAULT'
Wed Oct 23 12:17:54 2002: DEBUG: Rewrote user name to login
Wed Oct 23 12:17:54 2002: DEBUG: Deleting session for login, 192.168.16.204, 13
Wed Oct 23 12:17:54 2002: DEBUG: do query is: delete from RADONLINE where
NASIDENTIFIER='192.16
8.16.204' and NASPORT='13'
Wed Oct 23 12:17:54 2002: DEBUG: Handling with Radius::AuthRADMIN
Wed Oct 23 12:17:54 2002: DEBUG: Handling with Radius::AuthRADMIN:
Wed Oct 23 12:17:54 2002: DEBUG: Query is: select PASS_WORD from RADUSERS where
USERNAME='login
'
Wed Oct 23 12:17:54 2002: DEBUG: Query is: select ATTR_ID, VENDOR_ID, IVALUE, SVALUE,
ITEM_TYPE
from RADCONFIG where NAME='login' ORDER by ITEM_TYPE
Wed Oct 23 12:17:54 2002: DEBUG: Radius::AuthRADMIN looks for match with login
Wed Oct 23 12:17:54 2002: DEBUG: do query is: update RADUSERS set BADLOGINS=0 where
USERNAME='l
ogin'
Wed Oct 23 12:17:54 2002: DEBUG: Access accepted for login
Wed Oct 23 12:17:54 2002: DEBUG: do query is: insert into RADAUTHLOG (TIME_STAMP,
USERNAME, TYP
E) values (1035389874, 'login', 1)
Wed Oct 23 12:17:54 2002: DEBUG: Packet dump:
*** Sending to 192.168.16.204 port 1025
Packet length = 42
02 aa 00 2a 7c 2d 87 e0 c2 f8 cd 71 4c 4c 41 32
d1 62 f5 a8 1a 0f 00 00 17 3c 05 09 64 65 66 61
75 6c 74 12 07 68 65 6c 6c 6f
Code: Access-Accept
Identifier: 170
Authentic: <244>|>uw9<229><<191>zEC<223>RXv
Attributes:
Issanni-IP_Pool_Name = "default"
Reply-Message = "hello"
Wed Oct 23 12:17:55 2002: DEBUG: Packet dump:
*** Received from 192.168.16.204 port 1025
Packet length = 111
04 ab 00 6f 0e 7f 28 88 a4 38 ec ed 9d ca 1b 68
36 2d c6 59 01 07 6c 6f 67 69 6e 04 06 c0 a8 10
cc 05 06 00 00 00 0d 3d 06 00 00 00 05 06 06 00
00 00 02 08 06 c0 a8 2c 0b 09 06 ff ff ff ff 2c
07 50 50 50 3a 31 29 06 00 00 00 00 28 06 00 00
00 01 1a 14 00 00 17 3c 11 0e 61 74 6d 20 31 2f
30 3a 30 2e 33 32 2d 06 00 00 00 01 19 03 00
Code: Accounting-Request
Identifier: 171
Authentic: <14><127>(<136><164>8<236><237><157><202><27>h6-<198>Y
Attributes:
User-Name = "login"
NAS-IP-Address = 192.168.16.204
NAS-Port = 13
NAS-Port-Type = Virtual
Service-Type = Framed-User
Framed-IP-Address = 192.168.44.11
Framed-IP-Netmask = 255.255.255.255
Acct-Session-Id = "PPP:1"
Acct-Delay-Time = 0
Acct-Status-Type = Start
Issanni-Interface-Name = "atm 1/0:0.32"
Acct-Authentic = RADIUS
Class = ""
Wed Oct 23 12:17:55 2002: DEBUG: Handling request with Handler 'Realm=DEFAULT'
Wed Oct 23 12:17:55 2002: DEBUG: Rewrote user name to login
Wed Oct 23 12:17:55 2002: DEBUG: Adding session for login, 192.168.16.204, 13
Wed Oct 23 12:17:55 2002: DEBUG: do query is: delete from RADONLINE where
NASIDENTIFIER='192.16
8.16.204' and NASPORT='13'
Wed Oct 23 12:17:55 2002: DEBUG: do query is: insert into RADONLINE
(USERNAME,NASIDENTIFIER,NAS
PORT,ACCTSESSIONID,TIME_STAMP, FRAMEDIPADDRESS,NASPORTTYPE,SERVICETYPE) values
('login', '192.1
68.16.204', '13', 'PPP:1', '1035389875', '192.168.44.11', 'Virtual', 'Framed-User')
Wed Oct 23 12:17:55 2002: DEBUG: Handling with Radius::AuthRADMIN
Wed Oct 23 12:17:55 2002: DEBUG: Handling accounting with Radius::AuthRADMIN
Wed Oct 23 12:17:55 2002: DEBUG: do query is: replace ACCOUNTING
(ACCTOUTPUTOCTETS,ACCTINPUTOCT
ETS,ACCTSESSIONTIME,
ACCTSTATUSTYPE,USERNAME,TIME_STAMP,ACCTSESSIONID,ACCTDELAYTIME,FRAMEDIPADD
RESS, NASIDENTIFIER,NASPORT) values ('', '', '', 'Start', 'login', '1035389875',
'PPP:1', '0',
'192.168.44.11', '192.168.16.204', '13')
Wed Oct 23 12:17:55 2002: DEBUG: Accounting accepted
Wed Oct 23 12:17:55 2002: DEBUG: Packet dump:
*** Sending to 192.168.16.204 port 1025
Packet length = 20
05 ab 00 14 f
