- Freeradius-Users - lists.freeradius.org

EAP authentication stopped working
by larry tembu 04 May '13

04 May '13

Hi Freeradius users, i have FR freeradius-2.2.0-0.fc17.i686 set up on fedora 17 machine. the wimax clients are supplying EAPttls Mschapv2 for authentication. a few weeks ago, the configuration was working and authenticating, but it suddenly stopped. the users are created in the users file and below is the radiusd -X output. any more info required will be promptly provided. could someone help me out on this? the wimax system is 4M alvarion and the CPe are well configured. ignore_null = no } Module: Checking accounting {...} for more modules to load Module: Instantiating module "detail" from file /etc/raddb/modules/detail detail { detailfile = "/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } Module: Linked to module rlm_radutmp Module: Instantiating module "radutmp" from file /etc/raddb/modules/radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Linked to module rlm_attr_filter Module: Instantiating module "attr_filter.accounting_response" from file /etc/raddb/modules/attr_filter attr_filter attr_filter.accounting_response { attrsfile = "/etc/raddb/attrs.accounting_response" key = "%{User-Name}" relaxed = no } reading pairlist file /etc/raddb/attrs.accounting_response Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Instantiating module "attr_filter.access_reject" from file /etc/raddb/modules/attr_filter attr_filter attr_filter.access_reject { attrsfile = "/etc/raddb/attrs.access_reject" key = "%{User-Name}" relaxed = no } reading pairlist file /etc/raddb/attrs.access_reject } # modules } # server server inner-tunnel { # from file /etc/raddb/sites-enabled/inner-tunnel modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load } # modules } # server radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 0 } listen { type = "acct" ipaddr = * port = 0 } listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 46422 Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on command file /var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address * port 1814 Ready to process requests. rad_recv: Access-Request packet from host 11.0.0.205 port 1812, id=153, length=196 User-Name = "{sm=1}rawlacurone(a)adn.com" EAP-Message = 0x0201001e017b736d3d317d7261776c616375726f6e654061646e2e636f6d Message-Authenticator = 0x39a7eb8d6128461e0fa6caf5dd5c26c3 NAS-Identifier = "201" NAS-IP-Address = 11.0.0.205 Calling-Station-Id = "AC-81-12-78-CA-6E" WiMAX-BS-Id = 0xfff329010102 NAS-Port-Type = Wireless-802.16 Framed-MTU = 2000 Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 256 WiMAX-Release = "1.0" WiMAX-Accounting-Capabilities = IP-Session-Based WiMAX-Attr-1793 = 0x0000028a # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/11.0.0.205/auth-detail-20130501 [auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/11.0.0.205/auth-detail-20130501 [auth_log] expand: %t -> Wed May 1 17:46:27 2013 ++[auth_log] returns fail Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> {sm=1}rawlacurone(a)adn.com attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 153 to 11.0.0.205 port 1812 Waking up in 4.9 seconds. Cleaning up request 0 ID 153 with timestamp +1 Ready to process requests. rad_recv: Access-Request packet from host 11.0.0.205 port 1812, id=154, length=196 User-Name = "{sm=1}rawlacurone(a)adn.com" EAP-Message = 0x0201001e017b736d3d317d7261776c616375726f6e654061646e2e636f6d Message-Authenticator = 0x0ddedece670902a6348d2b16c392c015 NAS-Identifier = "201" NAS-IP-Address = 11.0.0.205 Calling-Station-Id = "AC-81-12-78-CA-6E" WiMAX-BS-Id = 0xfff329010102 NAS-Port-Type = Wireless-802.16 Framed-MTU = 2000 Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 256 WiMAX-Release = "1.0" WiMAX-Accounting-Capabilities = IP-Session-Based WiMAX-Attr-1793 = 0x0000028a # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/11.0.0.205/auth-detail-20130501 [auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/11.0.0.205/auth-detail-20130501 [auth_log] expand: %t -> Wed May 1 17:46:35 2013 ++[auth_log] returns fail Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> {sm=1}rawlacurone(a)adn.com attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 1 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 1 Sending Access-Reject of id 154 to 11.0.0.205 port 1812 Waking up in 4.9 seconds. Cleaning up request 1 ID 154 with timestamp +9 Ready to process requests. rad_recv: Access-Request packet from host 11.0.0.205 port 1812, id=155, length=196 User-Name = "{sm=1}rawlacurone(a)adn.com" EAP-Message = 0x0201001e017b736d3d317d7261776c616375726f6e654061646e2e636f6d Message-Authenticator = 0x8cbc1a4105e88c044aaa7a95df6dc98a NAS-Identifier = "201" NAS-IP-Address = 11.0.0.205 Calling-Station-Id = "AC-81-12-78-CA-6E" WiMAX-BS-Id = 0xfff329010102 NAS-Port-Type = Wireless-802.16 Framed-MTU = 2000 Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 256 WiMAX-Release = "1.0" WiMAX-Accounting-Capabilities = IP-Session-Based WiMAX-Attr-1793 = 0x0000028a # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/11.0.0.205/auth-detail-20130501 [auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/11.0.0.205/auth-detail-20130501 [auth_log] expand: %t -> Wed May 1 17:46:43 2013 ++[auth_log] returns fail Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> {sm=1}rawlacurone(a)adn.com attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 2 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 2 Sending Access-Reject of id 155 to 11.0.0.205 port 1812 Waking up in 4.9 seconds. Cleaning up request 2 ID 155 with timestamp +17 Ready to process requests. rad_recv: Access-Request packet from host 11.0.0.205 port 1812, id=157, length=196 User-Name = "{sm=1}rawlacurone(a)adn.com" EAP-Message = 0x0201001e017b736d3d317d7261776c616375726f6e654061646e2e636f6d Message-Authenticator = 0xd84871a21825f994c68593b4d78ca653 NAS-Identifier = "201" NAS-IP-Address = 11.0.0.205 Calling-Station-Id = "AC-81-12-78-CA-6E" WiMAX-BS-Id = 0xfff329010102 NAS-Port-Type = Wireless-802.16 Framed-MTU = 2000 Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 256 WiMAX-Release = "1.0" WiMAX-Accounting-Capabilities = IP-Session-Based WiMAX-Attr-1793 = 0x0000028a # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail [auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expan [auth_log] expand: %t -> Wed May 1 17:46:50 2013 ++[auth_log] returns fail Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> {sm=1}rawlacurone(a)adn.co attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 3 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 3 Sending Access-Reject of id 157 to 11.0.0.205 port 1812 Waking up in 4.9 seconds. ^C [root@adn larry]#

4 3

some error in log file
by Mehdi Ravanbakhsh 04 May '13

04 May '13

Hi All i have some error in log file and i do not know what is the cause of this error ? Error: WARNING: Unresponsive child for request 10785, in component authorize module WARNING: Module rlm_sql became unblocked for request 10526 Error: WARNING: Unresponsive child for request 10583, in component authorize module Error: WARNING: Unresponsive child for request 10561, in component authorize module sql WARNING: Unresponsive child for request 7478, in component authorize module <thread> best regards

2 1

freeeradius 3.0.0 issue
by BALSIANOK, Peter 04 May '13

04 May '13

Hi, Could you please fix following problems: Main configuration: # (1) Define two productioni/test home server(s). # Production home servers # Test home server. home_server wapgtw.test.system { type = acct ipaddr = x.x.x.x port = 1813 secret = ... status_check = none zombie_period = 40 revive_interval = 120 } # Put all of the servers into a pool. home_server_pool wapgtw.test.system { type = fail-over home_server = wapgtw.test.system } # (2) Define a realm for these home servers. # It should NOT be used as part of normal proxying decisions! realm wapgtw.test.system { acct_pool = wapgtw.test.system } # (3) Proxy configuration needs to be outside virtual server configuration listen { ipaddr = * port = 0 type = proxy } # (4) Global configuration for accounting listen { ipaddr = * port = 2813 type = acct virtual_server = wapgtw.test.system } # (5) Define accepted client(s) client 10.8.251.153 { secret = xxx shortname = xxx } # (6) Define a virtual server to handle production pre/post-proxy re-writing server wapgtw.test.system { preacct { # Insert preacct rules here preprocess linelog update control { Proxy-To-Realm := wapgtw.production.system } update reply { Fall-Through := No } update request { Called-Station-Id := "%{Called-Station-Id}.%{3GPP-SGSN-Address}" } } } radiusd: FreeRADIUS Version 3.0.0, for host x86_64-unknown-linux-gnu, built on May 2 2013 at 09:34:02 Copyright (C) 1999-2013 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. For more information about these matters, see the file named COPYRIGHT. Starting - reading configuration files ... ... Ready to process requests. rad_recv: Accounting-Request packet from host 10.8.251.153 port 58427, id=31, length=381 Acct-Status-Type = Start Event-Timestamp = "May 2 2013 12:00:39 CEST" Framed-IP-Address = 10.40.255.253 Called-Station-Id = "orangewap-ng" Calling-Station-Id = "421905xxxxxx" NAS-IP-Address = 10.8.251.153 NAS-Identifier = "10.8.251.153" Framed-Protocol = GPRS-PDP-Context Service-Type = Framed-User NAS-Port-Type = Virtual Acct-Session-Id = "D597D928a30003ad" 3GPP-IMSI = "231014450961399" 3GPP-IMSI-MCC-MNC = "23101" 3GPP-SGSN-Address = 213.151.252.35 3GPP-SGSN-MCC-MNC = "23101" 3GPP-NSAPI = "5" 3GPP-GGSN-Address = 213.151.217.40 3GPP-GGSN-MCC-MNC = "23101" 3GPP-Charging-Characteristics = "0800" 3GPP-IMEISV = "3529440557604301" 3GPP-RAT-Type = 1 3GPP-Location-Info = 0x0132f1100bfe659e 3GPP-Charging-ID = 2734687149 3GPP-PDP-Type = 0 3GPP-Charging-Gateway-Address = 0.0.0.0 3GPP-Selection-Mode = "1" Attr-26.10415.23 = 0x0801 3GPP-Negotiated-DSCP = 0 3GPP-GPRS-Negotiated-QoS-profile = "05-23921F9396D1FE74800000006400" (3) # Executing section preacct from file ./sites-enabled/robust-proxy-accounting (3) group preacct { (3) - entering group preacct {...} (3) [preprocess] = ok (3) linelog : expand: 'Accounting-Request.%{%{Acct-Status-Type}:-unknown}' -> 'Accounting-Request.1' WARNING: No such configuration item .Accounting-Request.1 (3) linelog : No such entry ".Accounting-Request.1" (3) [linelog] = noop (3) update control { (3) Proxy-To-Realm := "wapgtw.production.system" (3) } # update control = noop (3) update reply { (3) Fall-Through := No (3) } # update reply = noop (3) update request { (3) ERROR: %{Called-Station-Id}.%{3GPP-SGSN-Address} (3) ERROR: ^ Invalid regex reference Thank you very much. Peter Balšianok Data Service Operation Coordinator, Voice & Data Services Operations Orange Slovensko, a. s. Metodova 8, 821 08 Bratislava tel: +421 908 00 2405 mobil: +421 905 012 405 e-mail: peter.balsianok(a)orange.sk<mailto:peter.balsianok@orange.sk>

2 1

Valgrind memcheck FR 2.2.1shows memory leak
by Wang, Yu 03 May '13

03 May '13

Hello, I installed FR 2.2.1 from git on one of our radius servers on April 22. After installation, I ran valgrind memcheck against radiusd binary and it showed no memory leak. A few days later now, I ran valgrind again. It showed memory leak. I am not sure what caused it. I have valgrind memcheck output for you to review but its 7MB. I don't know if it's too big for posting or attaching it on this list. Please let me a way to post/send it without causing any trouble. I plan to upgrade our production server to 2.2.1 early next week and I am a little concerned with this memory leak check thing. Here is the radiusd -v: radiusd: FreeRADIUS Version 2.2.1 (git #c8eee19), for host i686-pc-linux-gnu, built on Apr 24 2013 at 11:10:03 Copyright (C) 1999-2013 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. For more information about these matters, see the file named COPYRIGHT. And here is the last few lines of valgrind -tool=memcheck /usr/local/sbin/radiusd: ==25076== HEAP SUMMARY: ==25076== in use at exit: 4,054,108 bytes in 83,682 blocks ==25076== total heap usage: 117,041 allocs, 33,359 frees, 6,027,616 bytes allocated ==25076== ==25076== LEAK SUMMARY: ==25076== definitely lost: 16 bytes in 3 blocks ==25076== indirectly lost: 0 bytes in 0 blocks ==25076== possibly lost: 2,730,037 bytes in 59,322 blocks ==25076== still reachable: 1,324,055 bytes in 24,357 blocks ==25076== suppressed: 0 bytes in 0 blocks ==25076== Rerun with --leak-check=full to see details of leaked memory ==25076== ==25076== For counts of detected and suppressed errors, rerun with: -v ==25076== Use --track-origins=yes to see where uninitialised values come from ==25076== ERROR SUMMARY: 647193 errors from 416 contexts (suppressed: 113 from 10) Thanks, Yu Wang Network Architect ITS, FSU

2 2

Re: Proxy Treatment of PAP/Chap Auth Types
by James T. Mugauri 03 May '13

03 May '13

Thanks for your usual indulgence and assistance, Alan and all. Much appreciated. I did the hopelessly illogical thing of testing it from an actual NAS associated with the proxy. The home server, which had been returning those rejects thus far, now accepted the user without fuss. Must be something specific to the configuration of radtest on proxy server, from which I had been testing. Having cleared that hurdle, I have a slight difficulty in accounting, if you have a minute, wise ones. Can the proxy server server log all accounting requests to the sql module before (or after?) it passes them on to the home server? Is there a switch i can test for (in the same way as notfound) in the accounting module that can prompt the proxy sql module to run even if the home server has marked the request handled? Many Thanks, JamesTM

1 0

Proxy Treatment of PAP/Chap Auth Types
by James T Mugauri 03 May '13

03 May '13

Hi, Hope someone can give me a pointer on this matter. We have 2 RADIUS installations, thus: 1. FreeRADIUS/mysql Version 2.1.1, in whose radcheck, Password attribute is 'User-Password' 2. FreeRADIUS/mysql Version 2.1.10, in whose radcheck, Password attribute is 'Cleartext-Password' On both freeradius servers sql and perl modules are enabled in authorize and accounting groups, and both servers accept PAP and CHAP auth if queried directly Server 2 is configured to proxy requests for unknown users for certain prefixes/suffixes to server 1, if perl and sql return no user: authorize { preprocess chap mschap digest eap { ok = return } files expiration logintime sql perl if (notfound) { suffix hotspotUser } pap } Challenge is, on Server 2, testing with radtest (passing the attributes so: radtest -t <type> iS_u2h4gna a2uwv localhost 1812 secret) , local users are authed fine, but non-local users always return with a reject. Debug output of server 1, if I use CHAP to attempt auth with radtest on server 2, is always: ++[pap] returns noop Found Auth-Type = CHAP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! Replacing User-Password in config items with Cleartext-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! Please update your configuration so that the "known good" !!! !!! clear text password is in Cleartext-Password, and not in User-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! +- entering group CHAP {...} [chap] login attempt by "iS_u2h4gna" with CHAP password [chap] Using clear text password "uz3f9" for user iS_u2h4gna authentication. [chap] Password check failed ++[chap] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} If, I use PAP with radtest on server 2, server 1 returns ++[pap] returns updated Found Auth-Type = PAP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! Replacing User-Password in config items with Cleartext-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! Please update your configuration so that the "known good" !!! !!! clear text password is in Cleartext-Password, and not in User-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! +- entering group PAP {...} [pap] login attempt with password "a2uwv" [pap] Using clear text password "uz3f9" [pap] Passwords don't match ++[pap] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} I have tried changing the "known good" clear text password on server 1 as recommended in the warning to no effect. (Is this because User-Password and Cleartext-Password must necessarily be the unequal and co-related)? If so, How can i convert 1 to the other? Hopefully, JamesTM --

4 5

segfault error
by Chris Taylor 02 May '13

02 May '13

I am running freeradius2-2.1.12-5.el5 on a CentOS server release 5.9 (Final). I was doing some testing on some new RADIUS servers that we want to put into production and I got the following error. /var/log/messages Apr 9 17:33:45 on-radius01 kernel: radiusd[8831]: segfault at 00002aae660ae000 rip 00002aae5b6215eb rsp 00002aae660ab7c8 error 4 What should I be looking for the RADIUS logs didn't turn up anything as it wasn't in debug mode. Thanks, Chris

4 16

post-proxy ip address assignment
by Gabriel Marais 02 May '13

02 May '13

hi guys i am having a hard time getting a post-proxy setup going. we have a freeradius 2.1.8 server setup for a specific realm. authentication requests are coming from a upstream provider (3g carrier) onto our radius server. our radius server sends the authentication request to another radius server (windows platform) that authenticates the user against active directory. we receive the response, either accepted or denied. if the response is 'user accepted', we must then do a mysql query to find the ip address for the relevant user from our freeradius server and ammend the ip address to the radius response back to the 3g carrier's radius server. the authentication part is working perfectly between our radius server and the microsoft radius server as we are either getting a positive or negative reponse from the microsoft radius server. Sending Access-Request of id 213 to x.x.x.x port 1812 User-Name = "jacobsb(a)tut.ac.za" User-Password = "Tut123" NAS-IP-Address = 127.0.1.1 NAS-Port = 8585 rad_recv: Access-Accept packet from host x.x.x.x port 1812, id=213, length=20 at this point, we need the ip address lookup to be done on the mysql server running on our freeradius server and insert the relevant information into the proxy reply back to the carrier. as far as i have been able to read up, this should be done in the post-proxy configuration using unlang at this post [ http://lists.freeradius.org/pipermail/freeradius-users/2008-May/027960.html] but I am not able to get this to work with the code as seen on the post mentioned. >>* post-proxy {*>>* ...*>>* if (proxy-reply:Framed-IP-Address) {*>>* update proxy-reply {*>>* Framed-IP-Address := 1.2.3.4*>>* ...*>>* }*>>* }*>>* }* Any pointers will be appreciated. Regards, Gabriel

2 6

Updating Reply Attributes in authenticate section
by Matthew Ceroni 01 May '13

01 May '13

In my authorize section I am matching LDAP groups to set VLAN attributes as such: if (Ldap-Group == "netCoreClass-IT") { update reply { Tunnel-Private-Group-Id:1 := 102 } } elsif (Ldap-Group == "netCoreClass-engineering") { update reply { Tunnel-Private-Group-Id:1 := 112 } } elsif (Ldap-Group == "netCoreClass-sales") { update reply { Tunnel-Private-Group-Id:1 := 116 } } elsif (Ldap-Group == "netCoreClass-HR_Facility") { update reply { Tunnel-Private-Group-Id:1 := 120 } } elsif (Ldap-Group == "netCoreClass-finance") { update reply { Tunnel-Private-Group-Id:1 := 124 } } Authentication is against Active Directory. So while a user may get assigned to a VLAN based of their group membership, if they fail to actually authenticate I want to change what VLAN they are assigned to (want to put them into a guest VLAN). How can I update reply attributes further down the chain? The reason I am doing this is I have an old Cisco wireless LAN controller that can't fall back to MAC 802.1x authentication. Therefore if a user fails with their credentials they fail to authenticate all together. So when coming from the wireless LAN controller I want always Accept. I tried putting the following in the users file: DEFAULT Called-Station-Id == "e8-40-40-cd-d6-10:sid_802" Tunnel-Type:1 = 13, Tunnel-Medium-Type:1 = 6, Tunnel-Private-Group-Id:1 = 104 Which accomplishes that radius never rejects even on a failed authentication, but the Tunnel-Private-Group:Id:1 doesn't get modified from what was set in the authorize section. Thanks

2 2

Repeating same TLV in a given VSA Issue
by Cholleti, Hanumantha 01 May '13

01 May '13

We have configured FreeRadius 2.1.12 on RedHat ; Requirement ========== In a given WiMax-Packet-Flow-Descriptor VSA, we want to have following multiple WiMAX-Uplink-Classifier (attribute 9) as shown in the below packet capture: WiMAX-Uplink-Classifier: =================== 1. permit in ip src any dst any 0-66 priority 3 2. permit in ip src any dst any 69-65535 priority 3 1st Packet Capture (Expected Behavior) =============================== AVP: l=125 t=Vendor-Specific(26) v=WiMAX(24757) VSA: l=119 t=WiMAX-Packet-Flow-Descriptor(28) C=0x00: 8 TLV(s) inside TLV: l=4 t=WiMAX-Packet-Data-Flow-Id(1): 111 WiMAX-Packet-Data-Flow-Id: 111 TLV: l=4 t=WiMAX-Service-Data-Flow-Id(2): 101 WiMAX-Service-Data-Flow-Id: 101 TLV: l=3 t=WiMAX-Direction(4): Uplink(1) WiMAX-Direction: Uplink (1) TLV: l=3 t=WiMAX-Activation-Trigger(5): 4 WiMAX-Activation-Trigger: 4 TLV: l=3 t=WiMAX-Transport-Type(6): IPv4-CS(1) WiMAX-Transport-Type: IPv4-CS (1) TLV: l=3 t=WiMAX-Uplink-QOS-Id(7): 111 WiMAX-Uplink-QOS-Id: 111 TLV: l=46 t=WiMAX-Uplink-Classifier(9): permit in ip src any dst any 0-66 priority 3 WiMAX-Uplink-Classifier: permit in ip src any dst any 0-66 priority 3 TLV: l=50 t=WiMAX-Uplink-Classifier(9): permit in ip src any dst any 69-65535 priority 3 WiMAX-Uplink-Classifier: permit in ip src any dst any 69-65535 priority 3 Configuration in MySQL ================== Here are the inserts we have in the radreply table: //--- WiMAX Capabilities attributes INSERT INTO radreply (username, attribute, op, value) VALUES ('testuser', 'WiMAX-Accounting-Capabilities', ':=', '1'), ('testuser', 'WiMAX-Hotlining-Capabilities', ':=', '1'), ('testuser', 'WiMAX-Idle-Mode-Notification-Cap', ':=', '0'), ('testuser', 'WiMAX-ROHC-Support', ':=', '01'); //--- WiMAX Packet Flow and QoS Descriptors - First Pair INSERT INTO radreply (username, attribute, op, value) VALUES ('testuser', 'WiMAX-Packet-Data-Flow-Id', ':=', '101'), ('testuser', 'WiMAX-Service-Data-Flow-Id', ':=', '101'), ('testuser', 'WiMAX-Direction', ':=', '2'), ('testuser', 'WiMAX-Activation-Trigger', ':=', '4'), ('testuser', 'WiMAX-Transport-Type', ':=', '1'), ('testuser', 'WiMAX-Downlink-QOS-Id', ':=', '101'), ('testuser', 'WiMAX-Downlink-Classifier', ':=', 'permit in any src any dst any priority 3'), ('testuser', 'WiMAX-QoS-Id', ':=', '101'), ('testuser', 'WiMAX-Schedule-Type', ':=', '2'), ('testuser', 'WiMAX-Traffic-Priority', ':=', '1'), ('testuser', 'WiMAX-Maximum-Sustained-Traffic-Rate', ':=', '22000000'), ('testuser', 'WiMAX-Minimum-Reserved-Traffic-Rate', ':=', '0'), ('testuser', 'WiMAX-Transmission-Policy', ':=', '208'); //--- WiMAX Packet Flow and QoS Descriptors - Second Pair //--- Note: Please note that change in the 'op' column value from the above //--- Since this is an additional packet flow and qos descriptor operator is set to '+=' instead of ':=' INSERT INTO radreply (username, attribute, op, value) VALUES ('testuser', 'WiMAX-Packet-Data-Flow-Id', '+=', '111'), ('testuser', 'WiMAX-Service-Data-Flow-Id', '+=', '101'), ('testuser', 'WiMAX-Direction', '+=', '1'), ('testuser', 'WiMAX-Activation-Trigger', '+=', '4'), ('testuser', 'WiMAX-Transport-Type', '+=', '1'), ('testuser', 'WiMAX-Uplink-QOS-Id', '+=', '111'), ('testuser', 'WiMAX-Uplink-Classifier', '+=', 'permit in ip src any dst any 0-66 priority 3'), ('testuser', 'WiMAX-Uplink-Classifier', '+=', 'permit in ip src any dst any 69-65535 priority 3'), ('testuser', 'WiMAX-QoS-Id', '+=', '111'), ('testuser', 'WiMAX-Schedule-Type', '+=', '5'), ('testuser', 'WiMAX-Traffic-Priority', '+=', '1'), ('testuser', 'WiMAX-Maximum-Sustained-Traffic-Rate', '+=', '5500000'), ('testuser', 'WiMAX-Minimum-Reserved-Traffic-Rate', '+=', '0'), ('testuser', 'WiMAX-Tolerated-Jitter', '+=', '1000'), ('testuser', 'WiMAX-Maximum-Latency', '+=', '1000'), ('testuser', 'WiMAX-Unsolicited-Grant-Interval', '+=', '40'), ('testuser', 'WiMAX-Transmission-Policy', '+=', '211'); Issue/Problem: ============ Version 2.1.2 and 2.20 -------------------------- In both FreeRadius versions 2.1.2 and 2.20 on RedHat, the 2nd Uplink-Classifier (permit in ip src any dst any 69-65535 priority 3) is showing up in a separate VSA on its own as shown below; Expecting to see it in the same VSA as show in the first packet capture. 2nd Packet Capture (Not an expected Behavior) ================================== AVP: l=125 t=Vendor-Specific(26) v=WiMAX(24757) VSA: l=119 t=WiMAX-Packet-Flow-Descriptor(28) C=0x00: 7 TLV(s) inside TLV: l=4 t=WiMAX-Packet-Data-Flow-Id(1): 111 WiMAX-Packet-Data-Flow-Id: 111 TLV: l=4 t=WiMAX-Service-Data-Flow-Id(2): 101 WiMAX-Service-Data-Flow-Id: 101 TLV: l=3 t=WiMAX-Direction(4): Uplink(1) WiMAX-Direction: Uplink (1) TLV: l=3 t=WiMAX-Activation-Trigger(5): 4 WiMAX-Activation-Trigger: 4 TLV: l=3 t=WiMAX-Transport-Type(6): IPv4-CS(1) WiMAX-Transport-Type: IPv4-CS (1) TLV: l=3 t=WiMAX-Uplink-QOS-Id(7): 111 WiMAX-Uplink-QOS-Id: 111 TLV: l=46 t=WiMAX-Uplink-Classifier(9): permit in ip src any dst any 0-66 priority 3 WiMAX-Uplink-Classifier: permit in ip src any dst any 0-66 priority 3 VSA: l=50 t=WiMAX-Packet-Flow-Descriptor(28) C=0x00: 1 TLV(s) inside TLV: l=50 t=WiMAX-Uplink-Classifier(9): permit in ip src any dst any 69-65535 priority 3 WiMAX-Uplink-Classifier: permit in ip src any dst any 69-65535 priority 3 Master Branch ------------------ If we configure the FreeRadius using the "Master" branch, we get the 2nd Uplink-Classifier in the same VSA as expected (as shown in the first packet capture) Wondering if the behavior in versions 2.1.2 and 2.20 is a bug and was fixed in the "master" branch or are we missing any configuration in 2.1.2/2.20 which is causing the undesired behavior? For our production implementation, don't want to go to the "master" branch if possible. Sorry for the last email, but want to provide as much details as possible. Thanks -Hanu

3 5