November 2013 - Freeradius-Users - lists.freeradius.org

Detailed Logging freeradius Request Packets
by Jean-Francois Mousinho 28 Oct '19

28 Oct '19

Hi, I've tried to find a way of detail logging the packets sent by freeradius to the client in the authentication phase but didn't found a way of doing it. Maybe I've not looked correctly so I'm asking if it's actually possible? I was able to log detailed packets sent by the client (Response packets) but not the ones sent by freeradius to the client (except accounting and proxied ones). Thanks for your time. Jean-François Mousinho

4 6

user-group for rejected users
by Fabricio Viana 21 Mar '17

21 Mar '17

Hello! Let´s suppose the following situations: 1) User exists but the password is wrong 2) User does not exist In both cases the answer is REJECT. It happens that certain hardware is making endless attempts that eventually saturating the server. - It is possible to cause the server, instead of rejecting the users, accept the login but responds ACCEPT with "framed-pool = pool-block" ? or/and - Is there any way to put REJECT users in a given group by default? Thanks! Fabricio

3 3

unlang vs suffix
by Rui Ribeiro 07 Nov '14

07 Nov '14

Hi, I have a simple doubt; I have seen many times a couple of people saying they prefer to use unlang than the suffix directive; what´s the advantage of - supposing proxy.conf is adequately configured, instead of doing suffix do instead (ignore the if part, I know it is missing in the example above, it is here just for the sake of clarity): if (!(User-Name =~ /^([^@]*)@(.+)$/)) { update reply { Reply-Message := "malformed username" } reject } else { update request { Stripped-User-Name := "%{1}" Realm := "%{2}" } if (Realm == "iscte.pt") { update control { Proxy-To-Realm := LOCAL } } else { update control { Proxy-To-Realm := EDUROAM } } } Regards, Rui Regards, Rui Ribeiro

7 8

AVP EAP-KEY name support in FR
by Srinu Bandari 12 May '14

12 May '14

Hi, We are trying to bring up MACsec with Cisco and FR, and we are stuck because of Radius unable to send EAP-Key-Name AVP. Below is what is expected as per RFC4072 RFC4072 says "A home Diameter server receiving a Diameter-EAP-Request with a Key-Name AVP with non-empty data MUST silently discard the AVP. In addition, the home Diameter server SHOULD include this AVP in Diameter-EAP-Response only if an empty EAP-Key-Name AVP was present in Diameter-EAP-Request." But radius server is not sending EAP-Key-Name AVP (Radius Attribute Type 102) even invalid AVP present in the Diameter-EAP-Request". Below is the debug print of radius Sending Access-Accept of id 647 to 10.20.64.9 port 1645 MS-MPPE-Recv-Key = 0x84e5c624c3bcdeadca3c6210f24bd7b8336921ccc1c58399d397afc75770332c MS-MPPE-Send-Key = 0xa6c4860cc8092c251502f5adc3ee13586e05fe84cbbb8b6793b08d9523d12b1f EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "user1" Does anyone have clue on this. Thanks, Srinivas CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

4 19

authorization based on ldap attribute
by Stefano Zanmarchi 29 Apr '14

29 Apr '14

Hallo, I've configured freeradius to authenticate users with PEAP, using openldap to store NTLM hashes. It works fine. Now I'd like to authorize only people who have the ldap attribute "haDirittoEduroam" set to Y (or the other way round: not to authorize users with "haDirittoEduroam" set to N). Below an example openldap entry. Is there an easy way to achive this? dn: uid=uto.ughi(a)myorg.it,dc=myorg,dc=it objectClass: sambaSamAccount objectClass: inetOrgPerson objectClass: person objectClass: dirittoEduroam cn: Uto sn: Ughi uid: uto.ughi(a)myorg.it haDirittoEduroam: N sambaSID: 121212 userPassword: {SSHA}EnK9jqiVGSPNi6EQwpqdpjThBJHtZ1fi sambaNTPassword: 2B466E3D3FB6AA4BF8AAAFEF8F59F6F3 sambaLMPassword: E52CAC67419A9A224300941ECC02054C thanks a lot for your help, Stefano

4 6

configuration parameters for perl module in rlm_perl
by Cornelius Kölbel 28 Mar '14

28 Mar '14

Hi list, is there are recommended way to pass configuration parameter to a rlm_perl module? My rlm_perl module, would need to have additional configuration parameters. I would like to avoid having the perl module read an additional configuration file. Is there a possibility to add such paramters somewhere in the freeradius config like in /etc/freeradius/modules/perl and than have the perl module access these parameters? Thanks a lot and kind regards Cornelius

8 20

how to change the radius default "testing123" password
by Clint Petty 10 Dec '13

10 Dec '13

I changed all instances of the password "testing123", to a random password on both the StrongSwan server and the Radius server, and restarted the strongswan and radiusd services. However, this broke the connection to authenticate to the LDAP server, so I had to put it back to "testing123" to get it to work again. How can I change the radius default "testing123" password? Is there a command I need to run to do this? Thanks for any help with this.

8 29

rlm_ldap (ldap): Could not start TLS: Connect error
by Hachmer, Tobias 05 Dec '13

05 Dec '13

Hello list, in my further tests with FreeRADIUS v3 (rpmbuild from v3.0.x branch) I have a problem with the ldap module and start_tls. This is definitely working: - Ldap connect with ldap utils (ldapsearch -ZZ and so on) via port 389 with starttls - Ldap connect with FreeRADIUS 2.1.12 via port 389 (start_tls = yes and require_cert = "demand") This is not working: - FR 3 ldap module isn't able to connect to ldap server via port 389 + start_tls=yes - FR debug error: # Loaded module rlm_ldap # Instantiating module "ldap" from file /etc/raddb/mods-enabled/ldap ldap { server = "fqdn" (matches CN in ldap server certificate) port = 389 password = "xxx" identity = "xxx" valuepair_attribute = "radiusVSA" read_clients = yes user { filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(objectClass=radiusProfile))" scope = "sub" base_dn = "xxx" access_attribute = "radiusAccountStatus" access_positive = yes } group { filter = "(objectClass=groupOfNames)" scope = "sub" base_dn = "xxx" name_attribute = "cn" membership_attribute = "memberOf" membership_filter = "(member=%{control:Ldap-UserDn})" cacheable_name = no cacheable_dn = yes } client { filter = "(objectClass=radiusClient)" scope = "sub" base_dn = "xxx" attribute { identifier = "radiusClientIdentifier" shortname = "radiusClientShortname" nas_type = "radiusClientType" secret = "radiusClientSecret" virtual_server = "radiusClientVirtualServer" require_message_authenticator = "radiusClientRequireMa" } } profile { filter = "(objectclass=radiusObjectProfile)" attribute = "radiusGroupName" default = "xxx" } options { ldap_debug = 597 chase_referrals = yes rebind = yes net_timeout = 1 res_timeout = 20 srv_timelimit = 20 idle = 60 probes = 3 interval = 3 } tls { ca_file = "/etc/raddb/certs/rootca_cert.pem" start_tls = yes require_cert = "demand" (also tested with never, same result) } } accounting { reference = "%{tolower:type.%{Acct-Status-Type}}" } post-auth { reference = "." } rlm_ldap (ldap): Initialising connection pool pool { start = 5 min = 4 max = 10 spare = 3 uses = 0 lifetime = 0 cleanup_delay = 5 idle_timeout = 60 spread = no } rlm_ldap (ldap): Opening additional connection (0) rlm_ldap (ldap): Connecting to fqdn:389 rlm_ldap (ldap): Could not start TLS: Connect error rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /etc/raddb/mods-enabled/ldap[8]: Instantiation failed for module "ldap" - openldap debug log: Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 1 descriptor Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: slap_listener_activate(7): Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 busy Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: >>> slap_listener(ldap:///) Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: listen=7, new connection on 16 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 1 descriptor Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: added 16r (active) listener=(nil) Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 2 descriptors Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: 16r Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: read active on 16 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: connection_get(16) Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: connection_get(16): got connid=1003 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: connection_read(16): checking for input on id=1003 Nov 28 11:21:00 radiusv3test slapd[7737]: op tag 0x77, time 1385634060 Nov 28 11:21:00 radiusv3test slapd[7737]: conn=1003 op=0 do_extended Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 1 descriptor Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: do_extended: oid=1.3.6.1.4.1.1466.20037 Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: send_ldap_extended: err=0 oid= len=0 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: send_ldap_response: msgid=1 tag=120 err=0 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 1 descriptor Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: 16r Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: read active on 16 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: connection_get(16) Nov 28 11:21:00 radiusv3test slapd[7737]: connection_get(16): got connid=1003 Nov 28 11:21:00 radiusv3test slapd[7737]: connection_read(16): checking for input on id=1003 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 1 descriptor Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 1 descriptor Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: 16r Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: read active on 16 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: connection_get(16) Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: connection_get(16): got connid=1003 Nov 28 11:21:00 radiusv3test slapd[7737]: connection_read(16): checking for input on id=1003 Nov 28 11:21:00 radiusv3test slapd[7737]: connection_read(16): TLS accept failure error=-1 id=1003, closing Nov 28 11:21:00 radiusv3test slapd[7737]: connection_closing: readying conn=1003 sd=16 for close Nov 28 11:21:00 radiusv3test slapd[7737]: connection_close: conn=1003 sd=16 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: removing 16 Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on 1 descriptor Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: activity on: Nov 28 11:21:00 radiusv3test slapd[7737]: Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=9 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=10 active_threads=0 tvp=zero Nov 28 11:21:00 radiusv3test slapd[7737]: daemon: epoll: listen=11 active_threads=0 tvp=zero FreeRADIUS 3: # ldd /usr/sbin/radiusd linux-vdso.so.1 => (0x00007fff8c1ff000) libfreeradius-server.so => /usr/lib64/freeradius/libfreeradius-server.so (0x00007f224b44b000) libfreeradius-radius.so => /usr/lib64/freeradius/libfreeradius-radius.so (0x00007f224b21b000) libfreeradius-eap.so => /usr/lib64/freeradius/libfreeradius-eap.so (0x00007f224b011000) libpcre.so.0 => /lib64/libpcre.so.0 (0x00007f224ade0000) libpcreposix.so.0 => /usr/lib64/libpcreposix.so.0 (0x00007f224abdd000) libtalloc.so.2 => /usr/lib64/libtalloc.so.2 (0x00007f224a9d3000) libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f224a639000) libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f224a3db000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f224a1c2000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2249fa8000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f2249da3000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2249b86000) libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f2249943000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f224970b000) libc.so.6 => /lib64/libc.so.6 (0x00007f2249378000) /lib64/ld-linux-x86-64.so.2 (0x00007f224b66d000) librt.so.1 => /lib64/librt.so.1 (0x00007f2249170000) libz.so.1 => /lib64/libz.so.1 (0x00007f2248f59000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f2248d15000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f2248a2f000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f224882a000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f22485fe000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f22483dd000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f2248170000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f2247f65000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f2247d62000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2247b42000) FreeRADIUS v2.1.12 (default RPM from official CentOS Repo): # ldd /usr/sbin/radiusd linux-vdso.so.1 => (0x00007fffa9980000) libfreeradius-radius-2.1.12.so => /usr/lib64/freeradius/libfreeradius-radius-2.1.12.so (0x00007fb0297b0000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb029591000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fb029377000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb02915a000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb028f22000) libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007fb028d19000) libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007fb028abc000) libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007fb028721000) libc.so.6 => /lib64/libc.so.6 (0x00007fb02838e000) /lib64/ld-linux-x86-64.so.2 (0x00007fb029c1e000) libfreebl3.so => /lib64/libfreebl3.so (0x00007fb028122000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fb027f1d000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fb027cd9000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fb0279f3000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fb0277ee000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fb0275c2000) libz.so.1 => /lib64/libz.so.1 (0x00007fb0273ac000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fb0271a0000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fb026f9d000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fb026d7d000) Thanks in advance for any help and please let me know if further information is needed. Kind regards, Tobias Hachmer

3 14

Crash problem with FR 2.x.x when background databases delay
by Jim Madden 04 Dec '13

04 Dec '13

This note is both a request for assistance in debugging a problem where I’m way out of my depth and a warning that there may be a crash problem lurking in the current 2.x.x code that won’t be visible until a server running it encounters an unusual delay from a back end system. I am not including much detailed diagnostic output because the problem I’m describing doesn’t happen under single threaded debugging and the debugging traces and core dumps that accumulate in multi-threaded mode are gigantic. We have been struggling with an attempted conversion of a Redhat compile-from-source Freeradius 2.2.1 deployment to a compile-from-source version of the latest 2.x.x code. Our very heavily loaded Radius servers provide MAC address and EAP/PEAP/TTLS authentication through a set of very creaky multi-use back-end Mysql servers which can occasionally go non-responsive for many seconds at a time. Ultimately I’d guess that we’ll switch to the FR 3 code but that change requires significant modification to a configuration that has grown up piecemeal over several years, so, in the meantime, we try to keep up with the FR 2 improvements. We’ll also fix our underlying load issues with hardware changes over the next few months, but for now, we have to live with them, so we see the problem described here if we try to advance beyond 2.2.1 code. Our 2.2.1 systems sometimes encounter database response delays that cause them to generate error messages like this Tue Nov 26 15:21:47 2013 : Error: Received conflicting packet from client Campus_WISM port 32770 - ID: 247 due to unfinished request 8533348. Giving up on old request. Tue Nov 26 15:21:50 2013 : Info: WARNING: Module rlm_eap became unblocked for request 8533348 but the servers continue to run. Under 2.2.3, the situation that produces these messages seems likely to generate a follow-on crash after a short period of time. The resulting crash dump shows that the failure is an illegal memory reference in a thread that has a normal seeming stack of modcall routines and code that is referencing a linked structure through a ‘request’ structure that has been damaged; the particular code that fails is not consistent but seems always to be a reference through a ‘request’; inspection of the broken request in the dump shows varying kinds of garbage; to get to the failed code, lots of earlier routines in the call stack would have used the same ‘request’ pointer value to extract data and apparently succeeded in doing so. It is as if some clean-up mechanism in another thread has destroyed the request while it is in use. Other threads in the server seem perfectly happy, waiting for their turn to get a request or to receive data from a database or ntlm_auth process. There seem always to be an error message like the one listed above in the log or log buffers. The crash does not happen under light load on the server and backend systems so that there are no conflicting packets, nor does it happen in unthreaded debug mode apparently because request processing happens sequentially. It does happen with radmin debugging turned on although those are so voluminous that it’s hard to extract useful information about what has happened. It is interesting that, even with backend delays, the crashes do not happen if I change the code in main/event.c that looks like int received_request(rad_listen_t *listener, ... /* * The new request is different from the old one, * but maybe the old is finished. If so, delete * the old one. */ switch (request->child_state) { struct timeval when; default: /* * Special hacks for race conditions. * The reply is encoded, and therefore * likely sent. We received a *new* * packet from the client, likely before * the next line or two of code which * updated the child state. In this * case, just accept the new request. */ if ((request->reply->code != 0) && request->reply->data) { radlog(L_INFO, "WARNING: Allowing fast client %s port %d - ID: %d for recent request %u.", client->shortname, packet->src_port, packet->id, request->number); remove_from_request_hash(request); request = NULL; break; } gettimeofday(&when, NULL); when.tv_sec -= 1; /* * If the cached request was received * within the last second, then we * discard the NEW request instead of the * old one. This will happen ONLY when * the client is severely broken, and is * sending conflicting packets very * quickly. */ if (timercmp(&when, &request->received, <)) { radlog(L_ERR, "Discarding conflicting packet from " "client %s port %d - ID: %d due to recent request %u.", client->shortname, packet->src_port, packet->id, request->number); return 0; } received_conflicting_request(request, client); request = NULL; break; to allow a 300 second leeway instead of the 1 second one so that in effect, received_conflicting_request is never called. I don’t think this particular code or most of its supporting routines have changed much between 2.2.1 and the current 2.x.x. My limited understanding of what’s happening here is that the server has matched a new incoming request with one that’s already in process and calls received_conflicting_request to try to terminate the on-going processing; this can leave an old request that’s waiting for some external event like a database request in process in an active thread but marked to stop when it comes to a sync point. After doing this marking, the code above then goes on to queue the newly arrived request to be worked on. I’m way out of my depth about how these two variants of the same request will be handled beyond this point in the server, but it appears that something has changed about it between the 2.2.1 code that works and the current 2.x.x code that crashes. I wonder if some table look-up or queuing mechanism has changed so that two threads processing these requests get confused about each others data? I will gladly provide more information under direction from the experts. I don’t want to flood the list with endless streams of useless debugging. Jim Madden UCSD Networking jmadden(a)ucsd.edu

3 3

LDAP Module : basedn empty -> error
by Dominique Fournier 02 Dec '13

02 Dec '13

Hi I try to connect my Freeradius to a Zimbra LDAP server with multidomain. In Zimbra, the LDAP tree is something like : "ou=people,dc=domain,dc=tld". I have some domains in ".fr" and some other in ".org". If I configure with the basedn = "dc=fr", Freeradius works well for all the domains in ".fr". But if I try to allow all my domains (with a basedn=""), Freeradius don't accept to authenticate the users. In the logs, when there is a reject, I can see : [ldap-inner-tunnel] performing user authorization for XXXXX [ldap-inner-tunnel] expand: (mail=%{User-Name}) -> (mail=XXXXX.fr) [ldap-inner-tunnel] expand: -> [ldap-inner-tunnel] unable to create basedn. ++[ldap-inner-tunnel] returns invalid Invalid user: [XXXXX.fr] (from client localhost port 0 via TLS tunnel) I found a topic in the list http://freeradius.1045715.n5.nabble.com/Sending-null-BaseDN-td5716006.html in 2012, but there is no solution. I am on a Debian stable Freeradius 2.1.12 Thanks a lot. Dom

3 10