July 2011 - Freeradius-Devel - lists.freeradius.org

Get rid of some absurd warnings
by Stephen R. van den Berg 09 Jul '11

09 Jul '11

--- During compilation I find numerous warnings. Some rather absurd, so it might make more sense to turn off the warnings instead; but just in case someone feels strongly about the warnings, here are some offered remedies. I'm using gcc 4.6. src/modules/rlm_ippool/rlm_ippool.c | 5 +++-- src/modules/rlm_ldap/rlm_ldap.c | 14 +++++++++----- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/src/modules/rlm_ippool/rlm_ippool.c b/src/modules/rlm_ippool/rlm_ippool.c index bdb8e35..6478e0c 100644 --- a/src/modules/rlm_ippool/rlm_ippool.c +++ b/src/modules/rlm_ippool/rlm_ippool.c @@ -342,7 +342,8 @@ static int ippool_accounting(void *instance, REQUEST *request) return RLM_MODULE_NOOP; } fr_MD5Init(&md5_context); - fr_MD5Update(&md5_context, xlat_str, strlen(xlat_str)); + fr_MD5Update(&md5_context, (unsigned char*)xlat_str, + strlen(xlat_str)); fr_MD5Final(key_str, &md5_context); key_str[16] = '\0'; fr_bin2hex(key_str,hex_str,16); @@ -499,7 +500,7 @@ static int ippool_postauth(void *instance, REQUEST *request) return RLM_MODULE_NOOP; } fr_MD5Init(&md5_context); - fr_MD5Update(&md5_context, xlat_str, strlen(xlat_str)); + fr_MD5Update(&md5_context, (unsigned char*)xlat_str, strlen(xlat_str)); fr_MD5Final(key_str, &md5_context); key_str[16] = '\0'; fr_bin2hex(key_str,hex_str,16); diff --git a/src/modules/rlm_ldap/rlm_ldap.c b/src/modules/rlm_ldap/rlm_ldap.c index 129e5ea..c53293d 100644 --- a/src/modules/rlm_ldap/rlm_ldap.c +++ b/src/modules/rlm_ldap/rlm_ldap.c @@ -677,7 +677,10 @@ ldap_instantiate(CONF_SECTION * conf, void **instance) } } #ifdef NOVELL - inst->atts[atts_num - 1] = "sasdefaultloginsequence"; + { + static char ts[] = "sasdefaultloginsequence"; + inst->atts[atts_num - 1] = ts; + } #endif inst->atts[atts_num] = NULL; @@ -765,7 +768,7 @@ read_mappings(ldap_instance* inst) operator = T_OP_INVALID; /* use defaults */ } else { ptr = opstring; - operator = gettoken(&ptr, buf, sizeof(buf)); + operator = gettoken((void*)&ptr, buf, sizeof(buf)); if ((operator < T_OP_ADD) || (operator > T_OP_CMP_EQ)) { radlog(L_ERR, "rlm_ldap: file %s: skipping line %i: unknown or invalid operator %s", filename, linenumber, opstring); @@ -989,7 +992,8 @@ static int ldap_groupcmp(void *instance, REQUEST *req, LDAPMessage *result = NULL; LDAPMessage *msg = NULL; char basedn[MAX_FILTER_STR_LEN]; - char *attrs[] = {"dn",NULL}; + static char firstattr[] = "dn"; + char *attrs[] = {firstattr,NULL}; char **vals; ldap_instance *inst = instance; char *group_attrs[] = {inst->groupmemb_attr,NULL}; @@ -1541,7 +1545,6 @@ static int ldap_authorize(void *instance, REQUEST * request) value = passwd_vals[i]; if (!value) continue; - create_attr: passwd_item = radius_paircreate(request, &request->config_items, attr, 0, @@ -1761,7 +1764,8 @@ static int ldap_authenticate(void *instance, REQUEST * request) LDAP *ld_user; LDAPMessage *result, *msg; ldap_instance *inst = instance; - char *user_dn, *attrs[] = {"uid", NULL}; + static char firstattr[] = "uid"; + char *user_dn, *attrs[] = {firstattr, NULL}; char filter[MAX_FILTER_STR_LEN]; char basedn[MAX_FILTER_STR_LEN]; int res; -- 1.7.5.4 -- Stephen.

2 1

DHCP compile fixes
by Stephen R. van den Berg 09 Jul '11

09 Jul '11

--- Trying to compile and use the DHCP server, I find these things that need to be fixed (code untested as yet, I intend to use the DHCP server in a production environment later this weekend). src/include/dhcp.h | 2 +- src/lib/dhcp.c | 4 ++-- src/lib/radius.c | 2 +- src/main/dhcpd.c | 8 ++++---- src/modules/rlm_ldap/rlm_ldap.c | 10 +++++----- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/src/include/dhcp.h b/src/include/dhcp.h index 63ab5e9..4305c0d 100644 --- a/src/include/dhcp.h +++ b/src/include/dhcp.h @@ -62,7 +62,7 @@ int fr_dhcp_decode(RADIUS_PACKET *packet); #define DHCP_UNPACK_OPTION1(x) (((x) & 0xff00) >> 8) #define PW_DHCP_MESSAGE_TYPE (53) -#define PW_DHCP_YOU_IP_ADDRESS (264) +#define PW_DHCP_YOUR_IP_ADDRESS (264) #define PW_DHCP_SUBNET_MASK (1) #define PW_DHCP_IP_ADDRESS_LEASE_TIME (51) diff --git a/src/lib/dhcp.c b/src/lib/dhcp.c index d234d60..5879135 100644 --- a/src/lib/dhcp.c +++ b/src/lib/dhcp.c @@ -1141,7 +1141,7 @@ int fr_dhcp_encode(RADIUS_PACKET *packet, RADIUS_PACKET *original) } } - vp = pairfind(packet->vps, DHCP2ATTR(256)); + vp = pairfind(packet->vps, 256, DHCP_MAGIC_VENDOR); if (vp) { *p++ = vp->vp_integer & 0xff; } else { @@ -1154,7 +1154,7 @@ int fr_dhcp_encode(RADIUS_PACKET *packet, RADIUS_PACKET *original) *p++ = 1; /* hardware type = ethernet */ *p++ = 6; /* 6 bytes of ethernet */ - vp = pairfind(packet->vps, DHCP2ATTR(259)); + vp = pairfind(packet->vps, 259, DHCP_MAGIC_VENDOR); if (vp) { *p++ = vp->vp_integer & 0xff; } else { diff --git a/src/lib/radius.c b/src/lib/radius.c index 5eb3ae3..6c09b4f 100644 --- a/src/lib/radius.c +++ b/src/lib/radius.c @@ -278,7 +278,7 @@ static int rad_sendto(int sockfd, void *data, size_t data_len, int flags, */ rcode = sendto(sockfd, data, data_len, flags, (struct sockaddr *) &dst, sizeof_dst); - if (rcode < 0) { +done: if (rcode < 0) { DEBUG("rad_send() failed: %s\n", strerror(errno)); } diff --git a/src/main/dhcpd.c b/src/main/dhcpd.c index c216bcf..5af566d 100644 --- a/src/main/dhcpd.c +++ b/src/main/dhcpd.c @@ -107,7 +107,7 @@ static int dhcp_process(REQUEST *request) /* * Hop count goes up. */ - vp = pairfind(request->reply->vps, DHCP2ATTR(259)); + vp = pairfind(request->reply->vps, 259, DHCP_MAGIC_VENDOR); if (vp) vp->vp_integer++; return 1; @@ -123,7 +123,7 @@ static int dhcp_process(REQUEST *request) * server. So we must be the destination of the * giaddr field. */ - pairdelete(&request->packet->vps, DHCP2ATTR(266)); + pairdelete(&request->packet->vps, 266, DHCP_MAGIC_VENDOR); rad_free(&request->reply); request->reply = request->packet; @@ -132,7 +132,7 @@ static int dhcp_process(REQUEST *request) /* * Search for client IP address. */ - vp = pairfind(request->packet->vps, DHCP2ATTR(264)); + vp = pairfind(request->packet->vps, 264, DHCP_MAGIC_VENDOR); if (!vp) { request->reply->code = 0; RDEBUG("DHCP: No YIAddr in the reply. Discarding packet"); @@ -151,7 +151,7 @@ static int dhcp_process(REQUEST *request) /* * Hop count goes down. */ - vp = pairfind(request->reply->vps, DHCP2ATTR(259)); + vp = pairfind(request->reply->vps, 259, DHCP_MAGIC_VENDOR); if (vp && (vp->vp_integer > 0)) vp->vp_integer--; /* diff --git a/src/modules/rlm_ldap/rlm_ldap.c b/src/modules/rlm_ldap/rlm_ldap.c index 8b08f6a..129e5ea 100644 --- a/src/modules/rlm_ldap/rlm_ldap.c +++ b/src/modules/rlm_ldap/rlm_ldap.c @@ -1580,7 +1580,7 @@ static int ldap_authorize(void *instance, REQUEST * request) if (res == 0){ passwd_val = universal_password; if (passwd_val){ - passwd_item = radius_paircreate(request, &request->config_items, PW_CLEARTEXT_PASSWORD, PW_TYPE_STRING); + passwd_item = radius_paircreate(request, &request->config_items, PW_CLEARTEXT_PASSWORD, 0, PW_TYPE_STRING); strlcpy(passwd_item->vp_strvalue,passwd_val,sizeof(passwd_item->vp_strvalue)); passwd_item->length = strlen(passwd_item->vp_strvalue); added_known_password = 1; @@ -1602,7 +1602,7 @@ static int ldap_authorize(void *instance, REQUEST * request) * The authorize method of no other LDAP module instance has * processed this request. */ - vp_inst = radius_paircreate(request, &request->config_items, inst_attr, PW_TYPE_STRING); + vp_inst = radius_paircreate(request, &request->config_items, inst_attr, 0, PW_TYPE_STRING); strlcpy(vp_inst->vp_strvalue, inst->xlat_name, sizeof(vp_inst->vp_strvalue)); vp_inst->length = strlen(vp_inst->vp_strvalue); @@ -1611,7 +1611,7 @@ static int ldap_authorize(void *instance, REQUEST * request) * of UP in the config items list and whether eDirectory account * policy check is to be performed or not. */ - vp_apc = radius_paircreate(request, &request->config_items, apc_attr, PW_TYPE_STRING); + vp_apc = radius_paircreate(request, &request->config_items, apc_attr, 0, PW_TYPE_STRING); if(!inst->edir_account_policy_check){ /* Do nothing */ strcpy(vp_apc->vp_strvalue, "1"); @@ -1649,7 +1649,7 @@ static int ldap_authorize(void *instance, REQUEST * request) auth_opt_attr = dattr->attr; if(pairfind(*check_pairs, auth_opt_attr, 0) == NULL){ if ((auth_option = ldap_get_values(conn->ld, msg, "sasDefaultLoginSequence")) != NULL) { - if ((vp_auth_opt = paircreate(auth_opt_attr, PW_TYPE_STRING)) == NULL){ + if ((vp_auth_opt = paircreate(auth_opt_attr, 0, PW_TYPE_STRING)) == NULL){ radlog(L_ERR, " [%s] Could not allocate memory. Aborting.", inst->xlat_name); ldap_msgfree(result); ldap_release_conn(conn_id, inst); @@ -1979,7 +1979,7 @@ retry: /* Generate state attribute */ state = rad_malloc(MAX_CHALLENGE_LEN); (void) sprintf(state, "%s%s", challenge, challenge); - vp_state = paircreate(PW_STATE, PW_TYPE_OCTETS); + vp_state = paircreate(PW_STATE, 0, PW_TYPE_OCTETS); memcpy(vp_state->vp_strvalue, state, strlen(state)); vp_state->length = strlen(state); pairadd(&request->reply->vps, vp_state); -- 1.7.5.4 -- Stephen.

1 0

Update debian packaging for v3
by Stephen R. van den Berg 09 Jul '11

09 Jul '11

--- In trying to compile the master branch for Debian, I find the following changes seem to be necessary (at least). Not quite sure if I covered everything, especially unclear of libfreeradius3 is necessary. Please review. debian/control | 8 ++++---- debian/freeradius-utils.install | 1 - debian/rules | 5 +++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/debian/control b/debian/control index 8c8ed39..dc3ccbc 100644 --- a/debian/control +++ b/debian/control @@ -28,7 +28,7 @@ Homepage: http://www.freeradius.org/ Package: freeradius Architecture: any -Depends: lsb-base (>= 3.1-23.2), ${shlibs:Depends}, freeradius-common, libfreeradius2 (= ${binary:Version}), ssl-cert, adduser +Depends: lsb-base (>= 3.1-23.2), ${shlibs:Depends}, freeradius-common, libfreeradius3 (= ${binary:Version}), ssl-cert, adduser Provides: radius-server Recommends: freeradius-utils Suggests: freeradius-ldap, freeradius-postgresql, freeradius-mysql, freeradius-krb5 @@ -54,7 +54,7 @@ Package: freeradius-utils Architecture: any Replaces: freeradius (<< 2.0) Conflicts: radiusd-livingston, yardradius -Depends: ${shlibs:Depends}, freeradius-common, libfreeradius2 (= ${binary:Version}) +Depends: ${shlibs:Depends}, freeradius-common, libfreeradius3 (= ${binary:Version}) Recommends: libdbi-perl Description: FreeRADIUS client utilities This package contains various client programs and utilities from @@ -72,7 +72,7 @@ Description: FreeRADIUS client utilities - rlm_ippool_tool - smbencrypt -Package: libfreeradius2 +Package: libfreeradius3 Architecture: any Depends: ${shlibs:Depends} Description: FreeRADIUS shared library @@ -82,7 +82,7 @@ Description: FreeRADIUS shared library Package: libfreeradius-dev Architecture: any Section: libdevel -Depends: ${shlibs:Depends}, libfreeradius2 (= ${binary:Version}) +Depends: ${shlibs:Depends}, libfreeradius3 (= ${binary:Version}) Description: FreeRADIUS shared library development files The FreeRADIUS projects' libfreeradius-radius and libfreeradius-eap, used by the FreeRADIUS server and some of the utilities. diff --git a/debian/freeradius-utils.install b/debian/freeradius-utils.install index 9bc0d62..ba91503 100644 --- a/debian/freeradius-utils.install +++ b/debian/freeradius-utils.install @@ -1,6 +1,5 @@ usr/bin/rlm_dbm_cat usr/bin/rlm_dbm_parser -usr/bin/radeapclient usr/bin/rlm_ippool_tool usr/bin/smbencrypt usr/bin/radclient diff --git a/debian/rules b/debian/rules index 10b7b75..49614ff 100755 --- a/debian/rules +++ b/debian/rules @@ -81,6 +81,7 @@ endif --enable-ltdl-install=no --enable-strict-dependencies \ --with-large-files --with-udpfromto --with-edir \ --enable-developer \ + --with-dhcp \ --config-cache \ --without-rlm_eap_tnc \ --with-rlm_sql_postgresql_lib_dir=`pg_config --libdir` \ @@ -152,14 +153,14 @@ install-arch: build-arch-stamp dh_testroot dh_installdirs -s test -d $(freeradius_dir)/usr/lib/freeradius || mkdir -p $(freeradius_dir)/usr/lib/freeradius - ln -s rlm_sql.so $(freeradius_dir)/usr/lib/freeradius/librlm_sql.so + ln -fs rlm_sql.so $(freeradius_dir)/usr/lib/freeradius/librlm_sql.so $(MAKE) install R=$(freeradius_dir) # rename radius binary to play nicely with others mv $(freeradius_dir)/usr/sbin/radiusd $(freeradius_dir)/usr/sbin/$(package) mv $(freeradius_dir)/$(mandir)/man8/radiusd.8 $(freeradius_dir)/$(mandir)/man8/$(package).8 - dh_install --sourcedir=$(freeradius_dir) -p libfreeradius2 + dh_install --sourcedir=$(freeradius_dir) -p libfreeradius3 dh_install --sourcedir=$(freeradius_dir) -p libfreeradius-dev for mod in ${modulelist}; do \ -- 1.7.5.4 -- Stephen.

1 0

Missing TLS Change Cipher Spec and TLS Finished in EAP-TLS exchanges
by arno＠natisbad.org 09 Jul '11

09 Jul '11

Hi, I upgraded an internal freeradius server (Linux, Debian unstable, libssl 0.9.8) used for EAP-TLS (802.11 WPA2 access) from 2.0.5 to 2.1.3. With 2.1.3, client authentication fails in the following way (wpasupplicant on Debian unstable, working with 2.0.5): - the TLS exchange is completed from freeradius point of view. It even sends the Access-Accept message to the NAS. - from the clients point of view, the TLS exchange is not over, it expects some more data from the server which are never sent. I took two pcap traces (sent to you privately, Alan), one with 2.0.5, one with 2.1.3. It looks like the TLS Change Cipher and TLS Tinished elements of the TLS exchange are not in the EAP encapsulated TLS packets sent by the server. Compare packet #23 of 2.1.3 trace with packet #27 of 2.0.5 trace. If you use wireshark, you will notice that the SSL layer is dissected; this is because #27 has a small brother: #29. It is not sent by 2.1.3. Alan, if you have an idea or a patch, I can test it on monday. Cheers, a+

5 15

Missing SSL Change Cipher Spec in EAP-TLS with Client Certificate verify failed
by yuqiang 08 Jul '11

08 Jul '11

Oh,I am sorry. But the problem i meet just like the event descibed in mailinglist here. I downloaded the new version of freeradius(2.1.10) and run it on LINUX.When the certificate is expired or invalid,I found the data sent by server were missed. The log is as followed.The exchange between client and server is not conformed to RFC5216 described as italic text. RFC 5216 Section 2.1 Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> /<- EAP-Request EAP-Type=EAP-TLS (TLS Alert message) / EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Failure (User Disconnected) the log: +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS TLS Length 225 [tls] Length Included [tls] eaptls_verify returned 11 [tls] <<< TLS 1.0 Handshake [length 0b8c], Certificate [tls] chain-depth=2, [tls] error=0 [tls] --> User-Name = test [tls] --> BUF-Name = ZJRoot,2.5.4.1 [tls] --> subject = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00R\x00o\x00o\x00t [tls] --> issuer = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00R\x00o\x00o\x00t [tls] --> verify return:1 [tls] chain-depth=1, [tls] error=0 [tls] --> User-Name = test [tls] --> BUF-Name = ZJCA,2.5.4.1 [tls] --> subject = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00C\x00A [tls] --> issuer = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00R\x00o\x00o\x00t [tls] --> verify return:1 --> verify error:num=10:certificate has expired [tls] >>> TLS 1.0 Alert [length 0002], fatal certificate_expired TLS Alert write:fatal:certificate expired TLS_accept: error in SSLv3 read client certificate B rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned SSL: SSL_read failed in a system call (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type Reject -- View this message in context: http://freeradius.1045715.n5.nabble.com/Missing-SSL-Change-Cipher-Spec-in-E… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

3 6

Re: [PATCH] Fix broken EAP-TLS (bug introduced 2008/08/24 by b51a3a82)
by Phil Mayers 08 Jul '11

08 Jul '11

The post is two years old. The bug is fixed. Upgrade to the latest version. Sent from my mobile, please excuse brevity and typos. ----- Reply message ----- From: "yuqiang" <yuqiang1973(a)163.com> To: <freeradius-devel(a)lists.freeradius.org> Subject: [PATCH] Fix broken EAP-TLS (bug introduced 2008/08/24 by b51a3a82) Date: Tue, Jul 5, 2011 15:12 Hi. Why not look at the mailing list,I want to your help! Best regards -- View this message in context: http://freeradius.1045715.n5.nabble.com/Missing-TLS-Change-Cipher-Spec-and-… Sent from the FreeRadius - Dev mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

2 1

Re: Patch to fix PPTP CHAP failure due to unknown-attribute problem
by freeradius developer/user identity 07 Jul '11

07 Jul '11

> You can find the current freeradius dictionaries at > https://github.com/alandekok/freeradius-server/tree/v2.1.x/share > You can see that dictionary.microsoft and dictionary.merit are there.... > ... > It includes attributes 11 (MS-CHAP-Challenge) and 25 (MS-CHAP2-Response). Thank you for your prompt reply! It turns out that the dictionary files for *radiusclient* are different from those for freeradius *server* in subtle ways. Specifically, the server version uses the type "octet" while radiusclient recognizes only "string", "integer", "ipaddr", and "date" (see radiusclient's lib/dict.c, which is what parses the dictionaries). You are completely correct that the freeradius server distribution comes with a whole bunch of dictionaries, and that the dictionary.microsoft one does define the attributes 11 and 25. Unfortunately, radiusclient does not read these and cannot process them correctly if it did read them. The radiusclient distribution (even the latest development version at cvs -d :pserver:anoncvs@cvs.freeradius.org:/source login CVS password: anoncvs cvs -d :pserver:anoncvs@cvs.freeradius.org:/source checkout radiusclient (c/o http://wiki.freeradius.org/Radiusclient) does not include any dictionary files other than "dictionary". Hence the problem. It certainly would be helpful to include radiusclient versions of dictionary.microsoft (and, I suppose, dictionary.merit) with the radiusclient distribution. Also, the current source of the radiusclient versions of dictionary.microsoft and dictionary.merit at http://wiki.freeradius.org/PopTop which is the source of the buggy version of dictionary.microsoft that has a space at the start of each line, could be updated to remove the spaces, and text could be inserted that explains that the errors rc_avpair_new: unknown attribute 11 rc_avpair_new: unknown attribute 25 may go away if these files are replaced with the revised versions. A good place for the text to be updated would be at the paragraph beginning, "That's not working. Ok, so you've followed the above steps and it's still not working. So lets double check things before you post to FreeRADIUS mailing lists: ...." I was hoping that my patches could be accepted in any case because there may be people who won't notice the changes in the web page above, and/or may have troubles with new dictionaries that they are developing. Another approach would be to modify radiusclient so that it reads the dictionaries used by freeradius server. That would make a lot of sense, and would be easy to do. Please let me know if you would like me to do that. Please let me know if I need to patch up the style in the patches. I tried to mimic the C-style of the original code, but may have missed spacing and such here and there. Thanks again for maintaining this important project. Please let me know how I can help. - Larry Widman

4 6

Re: Patch to fix PPTP CHAP failure due to unknown-attribute problem
by freeradius developer/user identity 06 Jul '11

06 Jul '11

On Wed, Jul 06, 2011 at 12:00:13PM +0200, freeradius-devel(a)lists.freeradius.org wrote: > Oh I see. Sorry, I wasn't even aware of that, and I've no idea if it's even > supported any more. > > I notice that the 'snapshots' link on that page points to an ftp server in > Turkey which doesn't have any content: > .... > All freeradius (server) development has moved to git - it's currently at > version 2.1.11. Sounds like a maintainer is needed under the auspices of the freeradius project: (from http://wiki.freeradius.org/Radiusclient) "Development of the radiusclient-ng and FreeRADIUS client were proceeding in parallel during 2006-2007,... until in early 2008 it has been decided to merge both projects ... and discontinue radiusclient-ng project.... All developers from the radiusclient-ng project joined FreeRADIUS team and few remaining fixes from the radiusclient-ng have been merged into FreeRADIUS client package. Development of the codebase is ongoing." The current latest version is on cvs.freeradius.org according to the page cited above. I was able to download a copy from there that was a tad more recent than the stable 1.1.6 version. Meanwhile, a search of github.com shows one project with "radius" and "client" in the name that is not related to Ruby or perl. It is "elagin / RadiusClient", and has just a few files. Interestingly, it was committed recently (2/18/2011). The size is 250K but most of the files are private and cannot be downloaded. The main.cpp file refers to radiusclient library functions but itself is not radiusclient. So, I'm not sure what this is but it does not appear to be the main site for radiusclient. So, it looks like radiusclient is currently not well supported within the freeradius project, and the name "radiusclient" is taken on github.com. If a maintainer is needed, I am willing to volunteer at least for now. Since the name "radiusclient" on github is taken, would it make sense to include radiusclient in the freeradius server source tree? That would be handy for those who want both, and it's not very large so people who don't want it wouldn't be bothered much. It could even be configured not to compile by default. Once the housekeeping (file transfer to github, updating the make files) is done, the first thing I would do is merge the dictionaries with the ones that come with the server! If there is a (dormant) maintainer already, I will be happy to work with him/her to do what is needed. Thanks - Larry Widman

2 1

radmin - infinite loop
by Brian Candler 06 Jul '11

06 Jul '11

This is with freeradius 2.1.10 The server is running as root (yes I know, but I can't change that easily right now). radmin works fine with: listen { type = control socket = ${run_dir}/${name}.sock uid = root mode = rw } Now, in order to step towards interfacing to a web app, I changed this to uid = www-data Of course, I can't yet connect from www-data because the server is running as root, and the socket is owned by 0/0 mode 550. But the strange thing is, if I run radmin as root, it no longer works; it doesn't even display the startup banner. strace shows that it's going into an infinite loop: ... set_tid_address(0x7f2fd45419d0) = 7688 set_robust_list(0x7f2fd45419e0, 0x18) = 0 futex(0x7fff3b496cdc, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fff3b496cdc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f2fd4541700) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7f2fd3abd870, [], SA_RESTORER|SA_SIGINFO, 0x7f2fd3ac78f0}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f2fd3abd900, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f2fd3ac78f0}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/freeradius/freeradius.sock"}, 37) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 ... etc forever I presume it's stuck here: /* * Read initial magic && version information. */ for (size = 0; size < 8; size += len) { len = read(sockfd, buffer + size, 8 - size); if (len < 0) { fprintf(stderr, "%s: Error reading initial data from socket: %s\n", progname, strerror(errno)); exit(1); } } And this I imagine is because of the uid test failing in the server, and the connection being dropped. Normally read() returning 0 would indicate an end-of-file condition, but for some reason that I don't understand, the socket is being set into non-blocking mode, so it's not as simple as that. However, I thought that if no data was available you'd get -1 and EAGAIN or EWOULDBLOCK? But as the code is currently written, it aborts on any condition where len < 0. I'm no expert in this area, but I suggest something like this (untested): for (size = 0; size < 8; ) { len = read(sockfd, buffer + size, 8 - size); if (len < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) continue; fprintf(stderr, "%s: Error reading initial data from socket: %s\n", progname, strerror(errno)); exit(1); } if (len == 0) { fprintf(stderr, "%s: Connection dropped by server\n", progname); exit(1); } size += len; } A couple of other suggestions. (1) When checking the uid of the socket peer, if you find it's 0 (root) you may as well let them in anyway. (2) When starting the control server, if the 'uid' or 'gid' values are set, it could try chown'ing or chgrp'ing the socket to that value. Thanks, Brian.

2 8

Patch to fix PPTP CHAP failure due to unknown-attribute problem
by freeradius developer/user identity 04 Jul '11

04 Jul '11

Since at least 2005, the combination of PPTP and radiusclient has led to failure of CHAP authentication with the following errors appearing in syslog: rc_avpair_new: unknown attribute 11 rc_avpair_new: unknown attribute 25 I have posted an analysis of the problem and a link to patch set against the CVS tree that fixes it (at least in my hands) at http://www.cardiothink.com/downloads/ The patches also add my name to the copyright: if this is not correct to do please take my name out. Also, I made the library able to use "INCLUDE" as well as "$INCLUDE", fixed what appeared to a problem with high-level directory specifications appearing after (but in alphabetical order) the subsidiary specifications in which they appeared in /Makefile.in, and added a simple program "radlistdictionary" that takes arguments to show the loading and processing of the dictionary and its included subdictionaries, at one of two levels of detail and in one of two forms of output (stdout, syslog). My hope is that this program will be helpful to others in debugging problems of this sort. In this case, the problem because obvious as soon as I ran it although it had been completely opaque before. Please let me know if it would be better for me to post the patches to this list directly rather than to refer to a web link. I don't want to clutter up the mailing list. The patch is 27K uncompressed and 7K compressed.

2 1