[RADIATOR] Problem parameter session-timeout
Augusto Cabrera
acabrera at etapa.net.ec
Wed May 25 16:48:57 CDT 2011
Hi, I need your help, I have the configuration of WIMAX and works well, the problem is that in the access accept the radiator back to the access equipment paametro session-timeout = 3600 default that makes 60-minute occasions that disconnecting users, I do not want my users log off, as I can delete this parameter to not send.
Thanks for your help
my configuration file is:
################################################################################################
<Handler TunnelledByTTLS=1>
# Implement MS Revocation List using a table in the SQL database
# Other modules such as SQl can be used. Required by Alcatel-Lucent
<AuthBy WIMAX>
Identifier AAA-WIMAX
# Details for accessing the SQL database that contains
# user/device passwords, Device-Sessions etc.
# This should match the username created in wimax.sql
DBSource dbi:mysql:wimax
DBUsername ss
DBAuth dd
# WiMAX is required to handle at least TTLS
# We can handle any tpe that generates MSK and EMSK
EAPType TTLS, TLS, PEAP, MSCHAP-V2, PSK, PAX, FAST, SIM, AKA
EAPTLS_CAFile /etc/ssl/cert1/Rootcacert.pem
EAPTLS_CertificateFile
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile
EAPTLS_PrivateKeyPassword 12
EAPTLS_MaxFragmentSize 1400
HAPassword mysecret
# AcctSQLStatement the same as AuthBy SQL
AccountingTable ACCOUNTING
AcctColumnDef STATUS_TYPE,Acct-Status-Type
AcctColumnDef WIMAX_BEGINNING_OF_SESSION,WiMAX-Beginning-Of-Session
AcctColumnDef SESSION_ID,Acct-Session-Id
AcctColumnDef FRAMED_IP_ADDRESS,Framed-IP-Address
AcctColumnDef NAI,User-Name
AcctColumnDef USER_NAME,Chargeable-User-Identity
AcctColumnDef STATION_ID,Calling-Station-Id
AcctColumnDef NAS_IDENTIFIER,NAS-Identifier
AcctColumnDef NAS_IP_ADDRESS,NAS-IP-Address
AcctColumnDef WiMAX_BS_ID,WiMAX-BS-ID
AcctColumnDef EVENT_TIMESTAMP,Event-Timestamp
AcctColumnDef HUAWEI_USER_PRIORITY,Huawei-User-Priority
AcctColumnDef SESSION_TIME,Acct-Session-Time
AcctColumnDef WIMAX_ACTIVE_TIME,WiMAX-Active-Time
AcctColumnDef INPUT_OCTETS,Acct-Input-Octets
AcctColumnDef OUTPUT_OCTETS,Acct-Output-Octets
AcctColumnDef TERMINATE_CAUSE,Acct-Terminate-Cause
</AuthBy>
</Handler>
#############################################################################################
# This works with the sample SQL tables created by
# goodies/wimax.sql
# test with goodies/wimaxtest as a simple test client
<Handler Client-Identifier=ClienteWimax, Realm=usbwimax>
# Implement MS Revocation List using a table in the SQL database
# Other modules such as SQl can be used. Required by Alcatel-Lucent
AuthByPolicy ContinueWhileAccept
<AuthBy SQL>
# Details for accessing the SQL database that contains
# user/device passwords, Device-Sessions etc.
# This should match the username created in wimax.sql
DefaultSimultaneousUse 1
DBSource dbi:mysql:wimax
DBUsername asa
DBAuth fd
NoEAP
Blacklist
AuthenticateAttribute Calling-Station-Id
# AuthSelect select reason from blacklist where nai=%0
AuthSelect SELECT blacklist.reason FROM blacklist, ONLINE WHERE nai=%0 OR ONLINE.ON_USER_NAME='%{Chargeable-User-Identity}'
AuthColumnDef 0, GENERIC, check
</AuthBy>
<AuthBy SQL>
DefaultSimultaneousUse 1
DBSource dbi:mysql:wimax
DBUsername mikem
DBAuth fred
NoEAP
Blacklist
AuthenticateAttribute Chargeable-User-Identity
# AuthSelect select reason from blacklist where nai=%0
AuthSelect SELECT blacklist.reason FROM blacklist, ONLINE WHERE ONLINE.ON_USER_NAME=%0
AuthColumnDef 0, GENERIC, check
</AuthBy>
<AuthBy WIMAX>
Identifier AAA-WIMAX
# Details for accessing the SQL database that contains
# user/device passwords, Device-Sessions etc.
# This should match the username created in wimax.sql
DefaultSimultaneousUse 1
Simultaneous-Use = 1
CaseInsensitivePasswords
RejectEmptyPassword
DBSource dbi:mysql:wimax
DBUsername mikem
DBAuth fred
# WiMAX is required to handle at least TTLS
# We can handle any tpe that generates MSK and EMSK
EAPType TTLS, TLS, PEAP, MSCHAP-V2, PSK, PAX, FAST, SIM, AKA
EAPTLS_CAFile /etc/ssl/cert1/Rootcacert.pem
EAPTLS_CertificateFile
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile
EAPTLS_PrivateKeyPassword 1234
EAPTLS_MaxFragmentSize 1400
HAPassword mysecret
# You can add support for simple accounting using
# AcctSQLStatement the same as AuthBy SQL
AccountingTable ACCOUNTING
AcctColumnDef STATUS_TYPE,Acct-Status-Type
AcctColumnDef WIMAX_BEGINNING_OF_SESSION,WiMAX-Beginning-Of-Session
AcctColumnDef SESSION_ID,Acct-Session-Id
AcctColumnDef FRAMED_IP_ADDRESS,Framed-IP-Address
AcctColumnDef NAI,User-Name
AcctColumnDef USER_NAME,Chargeable-User-Identity
AcctColumnDef STATION_ID,Calling-Station-Id
AcctColumnDef NAS_IDENTIFIER,NAS-Identifier
AcctColumnDef NAS_IP_ADDRESS,NAS-IP-Address
AcctColumnDef WiMAX_BS_ID,WiMAX-BS-ID
AcctColumnDef EVENT_TIMESTAMP,Event-Timestamp
AcctColumnDef HUAWEI_USER_PRIORITY,Huawei-User-Priority
AcctColumnDef SESSION_TIME,Acct-Session-Time
AcctColumnDef WIMAX_ACTIVE_TIME,WiMAX-Active-Time
AcctColumnDef INPUT_OCTETS,Acct-Input-Octets
AcctColumnDef OUTPUT_OCTETS,Acct-Output-Octets
AcctColumnDef TERMINATE_CAUSE,Acct-Terminate-Cause
</AuthBy>
<SessionDatabase SQL>
DefaultSimultaneousUse 1
Simultaneous-Use = 1
# SID, usuario y password con el que se conectará a Oracle
DBSource dbi:mysql:wimax
DBUsername mikem
DBAuth fred
AddQuery insert into ONLINE (ON_STATUS_TYPE, ON_FRAMED_IP_ADDRESS, ON_NAI, \
ON_USER_NAME, ON_STATION_ID, ON_EVENT_TIMESTAMP) \
values ('%{Acct-Status-Type}','%{Framed-IP-Address}','%{User-Name}', \
'%{Chargeable-User-Identity}','%{Calling-Station-Id}',%{Event-Timestamp})
CountQuery select ON_STATUS_TYPE, ON_FRAMED_IP_ADDRESS, ON_NAI, ON_USER_NAME, ON_STATION_ID, ON_EVENT_TIMESTAMP \
from ONLINE where ON_USER_NAME='%n'
DeleteQuery delete from ONLINE where (ON_STATION_ID='%{Calling-Station-Id}')
</SessionDatabase>
and log is
Code: Access-Request
Identifier: 114
Authentic: <0><0>j<11><0><0>$u<0><0>l5<0><0>_<129>
Attributes:
User-Name = "@usbwimax"
NAS-IP-Address = 3.3.3.3
Calling-Station-Id = "5c4ca9e2b87e"
NAS-Identifier = "WASN9770"
Event-Timestamp = 1306358673
EAP-Message = <2>\<0><6><21><0>
WiMAX-Capability = <1><5>1.1<2><3><2><3><3><1><5><3><1><4><3><1>
WiMAX-BS-ID = 00000203ec10
WiMAX-GMT-Timezone-Offset = -18000
NAS-Port-Type = Wireless-IEEE-802.16
WiMAX-PPAC = <1><6><0><0><0>c
Service-Type = Framed-User
Chargeable-User-Identity = ""
Message-Authenticator = S<178>1?<9><216>.<14><157><202><164><184>Yt/<186>
Wed May 25 16:25:54 2011: DEBUG: Handling request with Handler 'Client-Identifier=ClienteWimax, Realm=usbwimax', Identifier ''
Wed May 25 16:25:54 2011: DEBUG: Deleting session for @usbwimax, 3.3.3.3,
Wed May 25 16:25:54 2011: DEBUG: do query is: 'delete from ONLINE where (ON_STATION_ID='5c4ca9e2b87e')':
Wed May 25 16:25:54 2011: DEBUG: Handling with Radius::AuthSQL:
Wed May 25 16:25:54 2011: DEBUG: Handling with Radius::AuthSQL:
Wed May 25 16:25:54 2011: DEBUG: Query is: 'SELECT blacklist.reason FROM blacklist, ONLINE WHERE nai='5c4ca9e2b87e' OR ONLINE.ON_USER_NAME=''':
Wed May 25 16:25:54 2011: DEBUG: Radius::AuthSQL looks for match with 5c4ca9e2b87e [@usbwimax]
Wed May 25 16:25:54 2011: DEBUG: Radius::AuthSQL REJECT: No such user: 5c4ca9e2b87e [@usbwimax]
Wed May 25 16:25:54 2011: DEBUG: Query is: 'SELECT blacklist.reason FROM blacklist, ONLINE WHERE nai='DEFAULT' OR ONLINE.ON_USER_NAME=''':
Wed May 25 16:25:54 2011: DEBUG: AuthBy SQL result: ACCEPT, No such user
Wed May 25 16:25:54 2011: DEBUG: Handling with Radius::AuthSQL:
Wed May 25 16:25:54 2011: DEBUG: Handling with Radius::AuthSQL:
Wed May 25 16:25:54 2011: DEBUG: Query is: 'SELECT blacklist.reason FROM blacklist, ONLINE WHERE ONLINE.ON_USER_NAME=''':
Wed May 25 16:25:54 2011: DEBUG: Radius::AuthSQL looks for match with [@usbwimax]
Wed May 25 16:25:54 2011: DEBUG: Radius::AuthSQL REJECT: No such user: [@usbwimax]
Wed May 25 16:25:54 2011: DEBUG: Query is: 'SELECT blacklist.reason FROM blacklist, ONLINE WHERE ONLINE.ON_USER_NAME='DEFAULT'':
Wed May 25 16:25:54 2011: DEBUG: AuthBy SQL result: ACCEPT, No such user
Wed May 25 16:25:54 2011: DEBUG: Handling with Radius::AuthWIMAX: AAA-WIMAX
Wed May 25 16:25:54 2011: DEBUG: Handling with Radius::AuthWIMAX: AAA-WIMAX
Wed May 25 16:25:54 2011: DEBUG: Handling with EAP: code 2, 92, 6, 21
Wed May 25 16:25:54 2011: DEBUG: Response type 21
Wed May 25 16:25:54 2011: DEBUG: EAP result: 0,
Wed May 25 16:25:54 2011: DEBUG: Query is: 'select sessionid, mip_rk, mip_spi, fa_rk from device_session where sessionid=?': 7bf2c80a24afe1fe6b8f9dc33415b176
Wed May 25 16:25:54 2011: DEBUG: do query is: 'insert into device_session (outer_nai, sessionid, napid, bsid, nspid, msid, capabilities, timezoneoffset, nai, cui, mip_rk, mip_spi, fa_rk, key_expires) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)': @usbwimax 7bf2c80a24afe1fe6b8f9dc33415b176 000 002 5c4ca9e2b87e 0105312e31020302030301050301040301 -18000 etapainterno10 8f23073ee55ba131e14062792743c89bc0d5ea670a2753be3bd755f64becdbdb8c91ad0d46b493776990800309296aae619c218de4e25c8d380b45377994c188 4124871830 0fdf7a2ba3992cb6b5a9e38466543cf71aa21ca7 1306362354
Wed May 25 16:25:54 2011: DEBUG: AuthBy WIMAX result: ACCEPT,
Wed May 25 16:25:54 2011: DEBUG: Access accepted for 5c4ca9e2b87e
Wed May 25 16:25:54 2011: DEBUG: Packet dump:
*** Sending to 3.3.3.3 port 10068 ....
Packet length = 387
02 72 01 83 3c 10 bd 0e 56 eb 38 73 1d 5b e9 1b
56 3d cf 12 59 10 65 74 61 70 61 69 6e 74 65 72
6e 6f 31 30 4f 06 03 5c 00 04 50 12 2e 05 4b 6e
c9 7a 78 0a 1a 5e 6e 76 30 b1 81 58 1a 17 00 00
a1 a5 0a 06 ea 6c 78 d7 64 a8 3f 08 73 e8 cd f6
b0 97 f8 e0 d4 50 ed 06 68 09 84 89 15 03 03 0f
ba dc d2 2f ed 29 0c d9 3d 1a 0d 00 00 60 b5 10
07 00 d4 a5 db 39 1a 0d 00 00 60 b5 11 07 00 00
00 27 10
Code: Access-Accept
Identifier: 114
Authentic: <<16><189><14>V<235>8s<29>[<233><27>V=<207><18>
Attributes:
Chargeable-User-Identity = "etapainterno10"
EAP-Message = <3>\<0><4>
Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
WiMAX-Capability = <1><5>1.0<2><3><0><3><3><0><4><3><0>
WiMAX-AAA-Session-ID = "7bf2c80a24afe1fe6b8f9dc33415b176"
WiMAX-MSK = <142><241>{<180><153><194><206><193><29><180><143>t<239>lV[<23>v<191><128><219>H<239><173>+<136>[<207>Y<148>nm<31>2<6>v<141>1>}<152><173>}<160>+<132><136><13><168>|<234>"<23>'<2<180><239><128>kF<211>U<134>
Session-Timeout = 3600
Framed-MTU = 1400
WiMAX-FA-RK-KEY = <15><223>z+<163><153>,<182><181><169><227><132>fT<<247><26><162><28><167>
WiMAX-HA-RK-KEY = <238>)<153>G<184><170>vu<15><178><166>DLs<206>{<28><5>!R1<28>U<232><3^<15><183><216><212>q<250><167><12><15><148><128><21><215>w|f<170>y<182><7>/<162><170><12>p<199>n<203><9><31><139><168><182>S<184>U0
WiMAX-HA-RK-SPI = 3567639353
WiMAX-HA-RK-Lifetime = 10000
________________________________
De: radiator-bounces at open.com.au en nombre de radiator-request at open.com.au
Enviado el: mié 25/05/2011 3:39
Para: radiator at open.com.au
Asunto: radiator Digest, Vol 24, Issue 20
Send radiator mailing list submissions to
radiator at open.com.au
To subscribe or unsubscribe via the World Wide Web, visit
http://www.open.com.au/mailman/listinfo/radiator
or, via email, send a message with subject or body 'help' to
radiator-request at open.com.au
You can reach the person managing the list at
radiator-owner at open.com.au
When replying, please edit your Subject line so it is more specific
than "Re: Contents of radiator digest..."
Today's Topics:
1. Re: Top level radius servers problems (Esmeralda Pires)
2. Re: Top level radius servers problems (Alan Buxey)
----------------------------------------------------------------------
Message: 1
Date: Tue, 24 May 2011 20:38:23 +0100
From: Esmeralda Pires <epires at fccn.pt>
Subject: Re: [RADIATOR] Top level radius servers problems
To: radiator at open.com.au
Cc: "eduroam at fccn.pt" <eduroam at fccn.pt>
Message-ID: <4DDC092F.9030406 at fccn.pt>
Content-Type: text/plain; charset="windows-1252"
Hi,
If this was a problem related to the client running out of ID REQUEST
where can I look on the logs for a warning or something alerting that
this is happening?
And what are the recommendations to solve this kind of problem?
Thanks in advanced,
Best regards
Esmeralda
On 20-05-2011 20:21, Esmeralda Pires wrote:
> Hi All,
>
> We are having problems with our two top level radius servers. Both
> servers are Radiator (version: 4.7 with the latest patches) .
>
> When the problem occurs we look at the logs and we can see that we have
> some users that are constantly trying to authenticate and have no reply
> from their home institutions.
>
> Log example:
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (175)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (174)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (173)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (172)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (171)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (178)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (170)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (169)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (168)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (167)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (166)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (165)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (164)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (163)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (162)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (161)
>
> Fri May 20 16:11:21 2011: INFO: AuthRADIUS : No reply after 17 seconds
> and 0 retransmissions to x.x.x.x:1812 for userx at inst.pt (160)
>
> After a while more users starts to have the same problem. The worst
> scenario happens when all users have ?No reply after z second and y
> retransmissions?.
>
> Sometimes the service recovers on two or three minutes.
>
> Does anyone had similar problems on the past?
>
> Thanks in advanced
>
> Esmeralda C?mara
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20110524/afd2adec/attachment-0001.html
------------------------------
Message: 2
Date: Wed, 25 May 2011 09:39:10 +0100
From: Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
Subject: Re: [RADIATOR] Top level radius servers problems
To: Esmeralda Pires <epires at fccn.pt>
Cc: "eduroam at fccn.pt" <eduroam at fccn.pt>, "radiator at open.com.au"
<radiator at open.com.au>
Message-ID: <20110525083910.GB1408 at lboro.ac.uk>
Content-Type: text/plain; charset=us-ascii
Hi,
> If this was a problem related to the client running out of ID REQUEST
> where can I look on the logs for a warning or something alerting that this
> is happening?
welcome to the party. in the UK we have seen this issue to - and it doesnt take
that much until the server is all backlogged up and then other people to other
RADIUS servers get all messed up too.
> And what are the recommendations to solve this kind of problem?
from looking at the behaviour and working out the 'hit' that the RADIATOR
daemon takes for different issues I have found that dealing with incorrect
names (people sending junk to the national proxy) whilst annoying, a Reject
is quite 'cheap' for resources...its done quick and clears the socket for
use. a non responsive homesite causes the daemons UDP socket pipe to fill and disrupts
service for others...so, we recommend that sites have at least 2 RADIUS servers
(for resiliency) and have local monitoring so that they can see that their
site has issues..... its amazing how many still have just 1 RADIUS
server and no monitoring for it (!) :-(
the 'fix' that I have done is to implement a handler in the AuthBy clause for
noresponse - similar to the one supplied in goodies.txt - but not failing back to UNIX
local handler etc - therefore the user trying to connect to an unresponsive site
is just rejected. whilst not the best ultimate solution (their dumb client will
say something like 'wrong password' or such - it does stop the requests whacking
the server....up until the server is ready to retry the home site - about 60 seconds
IIRC from our config.
the OTHER issue - which I will be raising at higher level is that sites have got their NAS
kit bvadly configured - when this event happens we see thousands of requests for those
users coming in - the visited site should have EAP login limits on their NAS to stop brute-force
etc attacks - eg 3 logins in 60 seconds for a client etc. instead it looks like the kit
just keeps going anf going and going. relentless :-(
I can provide you config/snippet etc - and after discussion I hope for this (and a non related
FreeRADIUS config snippet I did for Japan earlier this week) to be in the european
eduroam wiki
alan
------------------------------
_______________________________________________
radiator mailing list
radiator at open.com.au
http://www.open.com.au/mailman/listinfo/radiator
End of radiator Digest, Vol 24, Issue 20
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20110525/ae1d6f4b/attachment-0001.html
More information about the radiator
mailing list