January 2016 - Freeradius-Users - lists.freeradius.org

Accept via calling-station value
by Munroe Sollog 20 Jan '16

20 Jan '16

I have an aruba wireless network where I am trying to get free-radius to auth a device based on calling-station id. Line 35 confirms my re-writing is working, but line 46 looks like it is rejecting the match even though it is listed in the authorized_macs file. Any help would be appreciated. Thanks. Here is my config: sites-enabled/default: http://paste.debian.net/hidden/059033f6/ policy.d/macauth: http://paste.debian.net/hidden/cefd55aa/ authorized_macs: http://paste.debian.net/hidden/992be562/ radius -X output: http://paste.debian.net/hidden/8492e2fd/ -- Munroe Sollog LTS - Network Analyst x85002

3 4

Re: freeradius 3.0.4 can't contact LDAP server
by Blangille Denis 20 Jan '16

20 Jan '16

> Michael Ströder wrote: >> Are you using LDAPS or LDAP with StartTLS? If yes, is the CA cert for validating >> the LDAP server cert properly configured? > Actually i'm work with ldap, i'm not working on security part, the ldaps server is not running. Anirudh Malhotra wrote : > Can you paste the ldap config? I'm using ApacheDS as ldap server, its config is divided in several file. Denis Blangille

2 1

EAP-TLS CRL problem - a PKIX guru around?
by tsouk 20 Jan '16

20 Jan '16

Hi Stefan, Had some CRL problems back in the day, with Apache 2.2 and Apache 2.4 behaving differently (I believe the change is in Apache 2.3, and I will have a whole blog post about this in the BBC internet blog soon). Have a look at the RFC (), under "6.3.3. CRL Processing", specifically: (b) Verify the issuer and scope of the complete CRL as follows: ... (2) If the complete CRL includes an issuing distribution point (IDP) CRL extension, check the following: (i) If the distribution point name is present in the IDP CRL extension and the distribution field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP. If the distribution point name is present in the IDP CRL extension and the distribution field is omitted from the DP, then verify that one of the names in the IDP matches one of the names in the cRLIssuer field of the DP. So I think this, in your CRL: X509v3 Issuing Distrubution Point: Full Name: URI:https://www.restena.lu/restena-staffauth.crl ...and this in your Cert... X509v3 CRL Distribution Points: Full Name: URI:https://www.restena.lu/ca/restena-root.crl ...might have to match. Let me know if this helps! Nikos

1 0

Re: EAP-TLS CRL problem - a PKIX guru around?
by tsouk 20 Jan '16

20 Jan '16

Hi Stefan, Had some CRL problems back in the day, with Apache 2.2 and Apache 2.4 behaving differently (I believe the change is in Apache 2.3, and I will have a whole blog post about this in the BBC internet blog soon). Have a look at the RFC (), under "6.3.3. CRL Processing", specifically: (b) Verify the issuer and scope of the complete CRL as follows: ... (2) If the complete CRL includes an issuing distribution point (IDP) CRL extension, check the following: (i) If the distribution point name is present in the IDP CRL extension and the distribution field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP. If the distribution point name is present in the IDP CRL extension and the distribution field is omitted from the DP, then verify that one of the names in the IDP matches one of the names in the cRLIssuer field of the DP. So I think this, in your CRL: X509v3 Issuing Distrubution Point: Full Name: URI:https://www.restena.lu/restena-staffauth.crl ...and this in your Cert... X509v3 CRL Distribution Points: Full Name: URI:https://www.restena.lu/ca/restena-root.crl ...might have to match. Let me know if this helps! Nikos

1 0

Strangeness in work 'radgroup_check_query' through 'rlm_sql_unixodbc'
by vanish 20 Jan '16

20 Jan '16

Hello, need help. 1. i have a test-machine with Ubuntu 14.04, Freeradius-server v2.1.12 and Informix Database Server v 10.00. 2. i use rlm_sql_unixodbc to connect Informix server. 3. When freeradius sends next simple request in Informix: group_membership_query = "select 'simult' groupname from TABLE(SET {1})" gets the answer: - rlm_sql_unixodbc: 07009 [unixODBC][Informix][Informix ODBC Driver]Invalid descriptor index. This request works in isql: SQL> select 'simult' groupname from TABLE(SET {1}); +----------+ | groupname| +----------+ | simul | +----------+ 4. Here the debug with '-X' option: Ready to process requests. rad_recv: Access-Request packet from host 10.10.10.10 port 47385, id=240, length=58 User-Name = "test" CHAP-Password = 0xf05090f9d0fd90909fdfdg112 Framed-Protocol = PPP # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++? if (Framed-Protocol == PPP) ? Evaluating (Framed-Protocol == PPP) -> TRUE ++? if (Framed-Protocol == PPP) -> TRUE ++- entering if (Framed-Protocol == PPP) {...} [chap] Setting 'Auth-Type := CHAP' +++[chap] returns ok ++- if (Framed-Protocol == PPP) returns ok ++[mschap] returns noop [sql] expand: %{User-Name} -> test [sql] sql_set_user escaped user --> 'test' rlm_sql (sql): Reserving sql socket id: 3 [sql] expand: SELECT first 1 1 id, '%{SQL-User-Name}' username, 'Password' attribute, trim(p.password) value, '==' op FROM acc a inner join details p on a.acc_id = p.acc_id WHERE username = '%{SQL-User-Name}' -> SELECT first 1 1 id, 'test' username, 'Password' attribute, trim(p.password) value, '==' op FROM acc a inner join details p on a.acc_id = p.acc_id WHERE username = 'test' WARNING: Found User-Password == "...". WARNING: Are you sure you don't mean Cleartext-Password? WARNING: See "man rlm_pap" for more information. [sql] User found in radcheck table [sql] expand: select 1 id, a.control username, 'Cisco-Account-Info' attribute, r.value value, '=' op from acc a inner join acc_b b on a.acc_id = b.acc_id inner join tq_p tp on tp.id = a.tq_p_id ............... and so on............... [sql] expand: select 'simult' groupname from TABLE(SET {1}) -> select 'simult' groupname from TABLE(SET {1}) rlm_sql_unixodbc: 07009 [unixODBC][Informix][Informix ODBC Driver]Invalid descriptor index. <---- Problem !!!! rlm_sql (sql): Released sql socket id: 3 ............... and so on............... 5. Others sql queries from dialup.conf such as: - nas_query - authorize_check_query - authorize_reply_query works well. 6. Is this bug only for group_membership_query? Does anyone experienced this ? -- ============================================ С уважением, Богучарский Иван Владимирович. Начальник СУТС ОРЭТС и ШПД ЗАО "Коламбия-Телеком". тел. 8-937-084-25-89.

2 6

Re: freeradius 3.0.4 can't contact LDAP server
by Blangille Denis 19 Jan '16

19 Jan '16

Michael Ströder wrote: > Are you using LDAPS or LDAP with StartTLS? If yes, is the CA cert for validating > the LDAP server cert properly configured? Actually i'm work with ldap, i'm not working on security part, the ldaps server is not running. Denis Blangille

2 1

rlm_ldap (ldap): 0 of 3 connections in use
by Marko Mernik 19 Jan '16

19 Jan '16

Hi! My server logs some strange things. What could be the problem? The radius server is working Ok Tue Jan 19 11:50:16 2016 : Warning: rlm_ldap (ldap): You probably need to lower "min" Tue Jan 19 11:50:18 2016 : Info: rlm_ldap (ldap): 0 of 3 connections in use. Need more spares Tue Jan 19 11:50:18 2016 : Info: rlm_ldap (ldap): Opening additional connection (83) Tue Jan 19 11:50:20 2016 : Info: rlm_ldap (ldap): 0 of 4 connections in use. Need more spares Tue Jan 19 11:50:20 2016 : Info: rlm_ldap (ldap): Opening additional connection (84) Tue Jan 19 11:50:20 2016 : Warning: rlm_ldap (ldap): You probably need to lower "min" Tue Jan 19 11:50:29 2016 : Info: rlm_ldap (ldap): 0 of 4 connections in use. Need more spares Tue Jan 19 11:50:29 2016 : Info: rlm_ldap (ldap): Opening additional connection (85) Tue Jan 19 11:50:29 2016 : Warning: rlm_ldap (ldap): You probably need to lower "min" Tue Jan 19 11:50:31 2016 : Info: rlm_ldap (ldap): 0 of 4 connections in use. Need more spares Tue Jan 19 11:50:31 2016 : Info: rlm_ldap (ldap): Opening additional connection (86) Tue Jan 19 11:50:42 2016 : Warning: rlm_ldap (ldap): You probably need to lower "min" Tue Jan 19 11:50:44 2016 : Info: rlm_ldap (ldap): 0 of 4 connections in use. Need more spares Tue Jan 19 11:50:44 2016 : Info: rlm_ldap (ldap): Opening additional connection (87) Tue Jan 19 11:51:26 2016 : Warning: rlm_ldap (ldap): You probably need to lower "min" Tue Jan 19 11:51:34 2016 : Info: rlm_ldap (ldap): 0 of 4 connections in use. Need more spares Tue Jan 19 11:51:34 2016 : Info: rlm_ldap (ldap): Opening additional connection (88) My config file: ldap { server = "172.17.0.232 172.17.0.27" identity = "cn=Manager,dc=example,dc=local" password = xxxxxxxxxxx base_dn = "dc=example,dc=local" valuepair_attribute = "radiusAttribute" update { control:Password-With-Header += 'userPassword' } user { base_dn = "${..base_dn}" filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" } group { base_dn = "${..base_dn}" filter = "(objectClass=posixGroup)" membership_attribute = "memberOf" } profile { } client { base_dn = "${..base_dn}" filter = '(objectClass=frClient)' attribute { identifier = 'radiusClientIdentifier' secret = 'radiusClientSecret' } } accounting { reference = "%{tolower:type.%{Acct-Status-Type}}" type { start { update { description := "Online at %S" } } interim-update { update { description := "Last seen at %S" } } stop { update { description := "Offline at %S" } } } } post-auth { update { description := "Authenticated at %S" } } options { chase_referrals = yes rebind = yes timeout = 4 timelimit = 3 net_timeout = 1 idle = 60 probes = 3 interval = 3 ldap_debug = 0x0028 } tls { } pool { start = 15 min = 5 max = ${thread[pool].max_servers} spare = 10 uses = 10 lifetime = 120 idle_timeout = 120 } } Thank you for response.

2 2

2.1 to 2.2 update question
by PENZ Robert 18 Jan '16

18 Jan '16

Hi! I know that it's an old version but anyway I hope someone can help me. The problem is with EAP-TLS and the freeradius upgrade von RHEL6 from 2.2.6 freeradius-2.1.12-6.el6.x86_64 to freeradius-2.2.6-4.el6.x86_64 last fall. The same configuration works on a freeradius 2.1.12 (and 2.2.0, but not 2.2.1 we compiled for testing). The error happens at the first packet, there is no TLS stuff. It looks like this on the 2.1.12. rad_recv: Access-Request packet from host 10.12.138.222 port 59774, id=0, length=165 User-Name = "DVT-DVT0060.tirol.local" Calling-Station-Id = "5C-26-0A-6E-84-2E" Framed-MTU = 1400 NAS-Port-Type = Ethernet NAS-Port-Id = "2:22" NAS-Port = 1022 NAS-IP-Address = 10.12.138.222 Connect-Info = "CONNECT 1000Mbs" Service-Type = Login-User EAP-Message = 0x0200001c014456542d445654303036302e7469726f6c2e6c6f63616c Message-Authenticator = 0xca7712ac53f23d4f869fc36646c0b841 ... ++? if (!EAP-Message) -> FALSE ++- entering else else {...} [eap] EAP packet type response id 0 length 28 [eap] No EAP Start, assuming it's an on-going EAP conversation +++[eap] returns updated ++- else else returns updated Found Auth-Type = EAP # Executing group from file /etc/raddb-fallback//sites-enabled/default +- entering group EAP {...} [eap] EAP Identity [eap] processing type tls [tls] Requiring client certificate [tls] Initiate [tls] Start returned 1 ++[eap] returns handled ++? if (invalid) .... Sending Access-Challenge of id 0 to 10.12.138.222 port 59774 EAP-Message = 0x010100060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xe5ec0911e5ed0403ee357f922ace544a Finished request 0. ..... On 2.2.6 I looks like this: rad_recv: Access-Request packet from host 127.0.0.1 port 33977, id=0, length=175 User-Name = "host/DVT-3N14N4J.tirol.local" Calling-Station-Id = "00-24-E8-3A-FA-66" Framed-MTU = 1400 NAS-Port-Type = Ethernet NAS-Port-Id = "2:22" NAS-Port = 1022 NAS-IP-Address = 127.0.0.1 Connect-Info = "CONNECT 1000Mbs" Service-Type = Login-User EAP-Message = 0x0200002101686f73742f4456542d334e31344e344a2e7469726f6c2e6c6f63616c Message-Authenticator = 0x904a22572d739d5a070b01dc941d1daa ++? if (!EAP-Message) -> FALSE ++else else { [eap] EAP packet type response id 0 length 33 [eap] No EAP Start, assuming it's an on-going EAP conversation +++[eap] = updated ++} # else else = updated +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /etc/raddb//sites-enabled/default +group EAP { [eap] EAP Identity [eap] processing type tls [tls] Requiring client certificate [tls] Initiate [tls] Start returned 1 ++[eap] = handled ++? if (ok) ? Evaluating (ok) -> FALSE ++? if (ok) -> FALSE ++else else { +++? if (EAP-Type == "NAK") ? Evaluating (EAP-Type == "NAK") -> FALSE +++? if (EAP-Type == "NAK") -> FALSE +++else else { ++++update control { ++++} # update control = noop +++} # else else = noop ++} # else else = noop ++? if (handled && (Response-Packet-Type == Access-Challenge)) ? Evaluating (handled ) -> FALSE ?? Skipping (Response-Packet-Type == Access-Challenge) ++? if (handled && (Response-Packet-Type == Access-Challenge)) -> FALSE +} # group EAP = noop Failed to authenticate the user. Login incorrect: [host/DVT-3N14N4J.tirol.local/<via Auth-Type = EAP>] (from client macau03_local port 1022 cli 0024e83afa66) Using Post-Auth-Type REJECT ..... Sending delayed reject for request 0 Sending Access-Reject of id 0 to 127.0.0.1 port 33977 EAP-Message = 0x010100060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xca5a2b60ca5b268f8efac2a79a6aa6aa We did check at which version the problem got introduced and found that 2.2.0 worked 2.2.1 did not anymore. The relevant config looks this way authenticate { ..... Auth-Type EAP { eap { handled = 1 invalid = 1 } if (ok) { if ("%{TLS-Client-Cert-Subject}" !~ /\/CN=%{sql:SELECT subject8021x FROM tdevices WHERE mac = '%{Calling-Station-Id}'}/i) { update control { MACAU-Reason := "Cert-Subject <%{TLS-Client-Cert-Subject}> entspricht nicht dem Hinterlegten --> Remediation Netz" } handled } # hat das EAP worked, need to overright the vlan, depending on the switch type elsif ("%{reply:Tunnel-Private-Group-ID}") { update reply { Tunnel-Private-Group-ID := "%{sql:SELECT ..... " } } elsif ("%{reply:Extreme-Netlogin-Extended-Vlan}") { update reply { Extreme-Netlogin-Extended-Vlan := "%{sql:SELECT ....." } } elsif ("%{reply:Xylan-Auth-Group}") { update reply { Xylan-Auth-Group := "%{sql:SELECT ...." } } # store that 802.1x worked update control { MACAU-Reason := "802.1x <%{TLS-Client-Cert-Subject}> authentifiziert" } # Delete Entries the switches don't like # <Warn:AAA.RADIUS.vsaUnknownVend> radDecodeVsa :Unknown vendor 311 16 # <Warn:AAA.RADIUS.vsaUnknownVend> radDecodeVsa :Unknown vendor 311 17 update reply { MS-MPPE-Recv-Key !* ANY MS-MPPE-Send-Key !* ANY } } else { # EAP did not work if (EAP-Type == "NAK") { update control { MACAU-Reason := "Nicht unterstuetzter EAP Typ --> Client Fehlkonfiguration" } } else { update control { MACAU-Reason := "Zertifikat ungueltig (z.b. revoked/abgelaufen)" } } } We also found out that just putting "eap" without {} and Auth-Type EAP just before that code block works - but then the rest of the code is not executed. Where should I put the set/update of the attributes in the newer versions of freeradius? Regards, Robert

3 2

Empty packet, socket not ready message
by Alex Sharaz 18 Jan '16

18 Jan '16

Hi, We've just upgraded one of our outward facing freeradius servers to Ubuntu 14.04. After the upgrade I rebuilt FR 2.2.9 and while tings are working, I'm now getting a lot of Error: Empty packey: socket not ready messages debug trace shows Thu Jan 14 13:45:54 2016 : Info: [attr_filter.access_reject] expand: %{User-Name} -> as1129@york .ac.uk Thu Jan 14 13:45:54 2016 : Debug: attr_filter: Matched entry DEFAULT at line 11 Thu Jan 14 13:45:54 2016 : Info: ++[attr_filter.access_reject] = updated Thu Jan 14 13:45:54 2016 : Info: +} # group REJECT = updated Thu Jan 14 13:45:54 2016 : Info: Delaying reject of request 67 for 1 seconds Thu Jan 14 13:45:54 2016 : Debug: Going to the next request Thu Jan 14 13:45:54 2016 : Debug: Thread 3 waiting to be assigned a request Thu Jan 14 13:45:55 2016 : Info: Sending delayed reject for request 23 Thu Jan 14 13:45:55 2016 : Info: Sending delayed reject for request 24 Thu Jan 14 13:45:55 2016 : Info: Sending duplicate proxied request to home server 194.83.56.233 por t 1812 - ID: 120 Thu Jan 14 13:45:55 2016 : Error: Empty packet: Socket is not ready. Thu Jan 14 13:45:55 2016 : Info: Sending duplicate proxied request to home server 194.83.56.233 por t 1812 - ID: 7 Thu Jan 14 13:45:55 2016 : Error: Empty packet: Socket is not ready. Thu Jan 14 13:45:55 2016 : Info: Sending delayed reject for request 39 Thu Jan 14 13:45:55 2016 : Info: Sending delayed reject for request 41 Sending Access-Accept of id 237 to 194.82.174.185 port 29981 or Thu Jan 14 13:45:51 2016 : Info: } # server eduroam Thu Jan 14 13:45:51 2016 : Info: Finished request 9. Thu Jan 14 13:45:51 2016 : Debug: Going to the next request Thu Jan 14 13:45:51 2016 : Debug: Thread 1 waiting to be assigned a request Thu Jan 14 13:45:51 2016 : Error: Empty packet: Socket is not ready. Thu Jan 14 13:45:51 2016 : Debug: Waking up in 0.3 seconds. Thu Jan 14 13:45:51 2016 : Debug: Waking up in 0.2 seconds. or Jan 14 13:45:50 2016 : Debug: rlm_perl: Added pair Proxy-State = 0x3236 Thu Jan 14 13:45:50 2016 : Debug: rlm_perl: Added pair State = 0x382b03450000013700010200c253f60c00 000000000000000000000000000004162412a2 Thu Jan 14 13:45:50 2016 : Debug: rlm_perl: Added pair NAS-Identifier = aruba0 Thu Jan 14 13:45:50 2016 : Debug: rlm_perl: Added pair NAS-IP-Address = 144.32.64.18 Thu Jan 14 13:45:50 2016 : Debug: rlm_perl: Added pair User-Name = hyuai(a)hyms.ac.uk Thu Jan 14 13:45:50 2016 : Debug: rlm_perl: Added pair Message-Authenticator = 0x82e775ee97b58da33b 734bd29026433c Thu Jan 14 13:45:50 2016 : Debug: rlm_perl: Added pair Calling-Station-Id = CC-3A-61-B4-4C-5D Thu Jan 14 13:45:50 2016 : Info: ++[perl] = ok Thu Jan 14 13:45:50 2016 : Info: +} # group pre-proxy = updated Thu Jan 14 13:45:50 2016 : Info: Proxying request 4 to home server 194.83.56.233 port 1812 Thu Jan 14 13:45:50 2016 : Debug: Going to the next request Thu Jan 14 13:45:50 2016 : Debug: Thread 1 waiting to be assigned a request Thu Jan 14 13:45:50 2016 : Error: Empty packet: Socket is not ready. Thu Jan 14 13:45:50 2016 : Debug: Waking up in 0.2 seconds. Any other info reuired to find out why this is now happening? Rgds Alex

5 10

Freeradius 3.0.10 sigsegv
by Luca Palazzo 18 Jan '16

18 Jan '16

Hi, we are experiencing a lot of segmentation fault in freeradius 3.0.10. It seems to be something in proxy because we have other freeradius server running without problem. Those one (other two servers) with proxy enabled crash with the same backtrace. Hosts configuration and backtrace follows. Any idea? Thanks in advance Luca Freeradius version is: freeradius: FreeRADIUS Version 3.0.10, for host x86_64-pc-linux-gnu, built on Dec 15 2015 at 10:46:38 The proxy.conf is: proxy server { default_fallback = yes } home_server radius.radius.net { type = auth+acct ipaddr = xxxx port = 1812 secret = "password" status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server radius2.radius.net { type = auth+acct ipaddr = xxx port = 1812 secret = "password" status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server_pool EDUROAM-IT { type = fail-over home_server = radius.radius.net home_server = radius2.radius.net } realm unict.it { # nostrip } realm NULL { nostrip } realm LOCAL { nostrip } realm DEFAULT { pool = EDUROAM-IT nostrip type = radius } eduroam virtual server is: server eduroam { authorize { auth_log suffix if ((control:Proxy-To-Realm == "DEFAULT") && (User-Name =~ /.*@.*.unict.it$/)) { update control { Proxy-To-Realm := NULL } } eap } authenticate { Auth-Type EAP { eap } } preacct { # detail suffix if ((control:Proxy-To-Realm == "DEFAULT") && (User-Name =~ /.*@.*.unict.it$/)) { update control { Proxy-To-Realm := NULL } } } accounting { sql } post-auth { reply_log Post-Auth-Type REJECT { # reply_log } } pre-proxy { attr_filter.pre-proxy pre_proxy_log } post-proxy { post_proxy_log attr_filter.post-proxy } } Here is the backtrace (the same for both of servers): #0 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xa531c0, req_list=0xa53470, check=check@entry=0xa54ce0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 #1 0x00007ffff7bb95d7 in cond_cmp_values (request=0xa531c0, lhs_type=<optimized out>, lhs=<optimized out>, lhs_len=<optimized out>, rhs_type=PW_TYPE_STRING, rhs=0x7fffffffd2d0, rhs_len=8, c=<optimized out>, c=<optimized out>) at src/main/evaluate.c:315 #2 0x00007ffff7bb992a in cond_normalise_and_cmp (request=0x0, c=0x8bd4a0, lhs_type=PW_TYPE_INVALID, lhs_enumv=0x7ffff7bd4230, lhs_enumv@entry=0x0, lhs=0x0, lhs_len=1, lhs_len@entry=0) at src/main/evaluate.c:544 #3 0x00007ffff7bba3ac in radius_evaluate_map (request=request@entry=0xa531c0, modreturn=modreturn@entry=10, depth=depth@entry=0, c=c@entry=0x8bd4a0) at src/main/evaluate.c:612 #4 0x00007ffff7bba4a0 in radius_evaluate_cond (request=0xa531c0, modreturn=10, depth=0, c=0x8bd4a0) at src/main/evaluate.c:708 #5 0x0000000000425228 in modcall_recurse (request=0xa531c0, component=22, depth=22, entry=0x7fffffffdec8, do_next_sibling=false) at src/main/modcall.c:479 #6 0x0000000000424fa9 in modcall_child (request=<optimized out>, component=<optimized out>, depth=<optimized out>, entry=0x7fffffffdeb0, c=<optimized out>, result=0x7fffffffd724, do_next_sibling=true) at src/main/modcall.c:408 #7 0x00000000004252c4 in modcall_recurse (request=0xa531c0, component=22, depth=22, entry=0x7fffffffdeb0, do_next_sibling=false) at src/main/modcall.c:785 #8 0x0000000000424fa9 in modcall_child (request=<optimized out>, component=<optimized out>, depth=<optimized out>, entry=0x7fffffffde98, c=<optimized out>, result=0x7fffffffd9c4, do_next_sibling=true) at src/main/modcall.c:408 #9 0x00000000004252c4 in modcall_recurse (request=0xa531c0, component=22, depth=22, entry=0x7fffffffde98, do_next_sibling=false) at src/main/modcall.c:785 #10 0x0000000000424fa9 in modcall_child (request=<optimized out>, component=<optimized out>, depth=<optimized out>, entry=0x7fffffffde80, c=<optimized out>, result=0x7fffffffdc64, do_next_sibling=true) at src/main/modcall.c:408 #11 0x00000000004252c4 in modcall_recurse (request=0xa531c0, component=22, component@entry=MOD_AUTHORIZE, depth=22, depth@entry=0, entry=0x7fffffffde80, do_next_sibling=false, do_next_sibling@entry=true) at src/main/modcall.c:785 #12 0x0000000000426416 in modcall (component=component@entry=MOD_AUTHORIZE, c=c@entry=0x9c22b0, request=request@entry=0xa531c0) at src/main/modcall.c:1130 #13 0x00000000004210dd in indexed_modcall (comp=MOD_AUTHORIZE, idx=<optimized out>, request=0xa531c0) at src/main/modules.c:1009 #14 0x0000000000410911 in rad_authenticate (request=0xa531c0) at src/main/auth.c:490 #15 0x000000000043409a in request_running (request=0xa531c0, action=<optimized out>) at src/main/process.c:1527 #16 0x0000000000430126 in request_queue_or_run (request=request@entry=0xa531c0, process=process@entry=0x433ee0 <request_running>) at src/main/process.c:1015 #17 0x0000000000431815 in request_receive (ctx=ctx@entry=0xa52a40, listener=listener@entry=0x9ef500, packet=0xa52aa0, client=client@entry=0x972b20, fun=fun@entry=0x4104b0 <rad_authenticate>) at src/main/process.c:1782 #18 0x000000000041bd5e in auth_socket_recv (listener=0x9ef500) at src/main/listen.c:1568 ---Type <return> to continue, or q <return> to quit--- #19 0x000000000042e72e in event_socket_handler (xel=<optimized out>, fd=<optimized out>, ctx=<optimized out>) at src/main/process.c:4556 #20 0x00007ffff7994025 in fr_event_loop (el=0x8e4640) at src/lib/event.c:641 #21 0x0000000000435531 in radius_event_process () at src/main/process.c:5621 #22 0x000000000040f7cc in main (argc=<optimized out>, argv=0x7fffffffecc8) at src/main/radiusd.c:579

4 15