December 2010 - Freeradius-Devel - lists.freeradius.org

Donation of free OATH Feitian OTP c200
by Jean-Michel Pouré - GOOZE 22 Dec '10

22 Dec '10

Dear Friends, In order to foster Free Software development, GOOZE is happy to donate free Feitian OTP c200 to the FreeRadius project. Technical details: * Compliant with OATH TOTP algorithm. * 6 Character LCD Screen * Water Resistance Certificate IP68 * Seed code sent by postal mail. To apply for a free OTP c200, visit this page: http://www.gooze.eu/feitian-otp-c200-for-free-software-development We only ship to Europe, Canada and the US. Merry Christmas and Happy new year. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu

1 0

patch for src/main/xlat.c
by Gabriel Blanchard 19 Dec '10

19 Dec '10

the exact same as %S but prefers to use the Event-Timestamp VP if it's available. I found that when I use a detail file to decouple accounting the timestamp gets skewed if there is any kind of delay to relay the logs. This way the original timestamp of the event is used which I believe is more accurate. --- freeradius-server-2.1.10/src/main/xlat.c 2010-09-28 07:03:56.000000000 -0400 +++ freeradius/src/main/xlat.c 2010-12-17 14:42:31.000000000 -0500 @@ -1166,6 +1166,27 @@ } p++; break; + case 'E': /* Event-Timestamp (Original Timestamp from the NAS) + * falls back to local timestamp if the vp isn't in the packet + */ + tmp = pairfind(request->packet->vps,PW_EVENT_TIMESTAMP); + if (tmp) { + TM = localtime_r(&tmp->vp_date, &s_TM); + len = strftime(tmpdt, sizeof(tmpdt), "%Y-%m-%d %H:%M:%S", TM); + if (len > 0) { + strlcpy(q, tmpdt, freespace); + q += strlen(q); + } + } else { + TM = localtime_r(&request->timestamp, &s_TM); + len = strftime(tmpdt, sizeof(tmpdt), "%Y-%m-%d %H:%M:%S", TM); + if (len > 0) { + strlcpy(q, tmpdt, freespace); + q += strlen(q); + } + } + p++; + break; case 'H': /* request hour */ TM = localtime_r(&request->timestamp, &s_TM); len = strftime(tmpdt, sizeof(tmpdt), "%H", TM);

2 1

radutmp
by Gabriel Blanchard 16 Dec '10

16 Dec '10

any reason why the session_id is limited to only 8 bytes in radutmp? It's truncating my session_ids by 2 bytes and caused me a lot of headaches :P Would it break anything if I'd just increase it to 32 bytes? While we're at it, why not change the login to 64 bytes as well? I can implement it and submit a patch...just thought I'd email the list first to make sure I'm not doing anything stupid. include/radutmp.h struct radutmp { char login[32]; /* Loginname */ /* FIXME: extend to 48 or 64 bytes */ unsigned int nas_port; /* Port on the terminal server (32 bits). */ char session_id[8]; /* Radius session ID (first 8 bytes at least)*/ /* FIXME: extend to 16 or 32 bytes */ -Gabe

2 2

building freeradius statically
by Verma Anurag-VNF673 15 Dec '10

15 Dec '10

Hi, I am trying to build static version of freeradius by passing --enable-static --enable-shared=no to configure. However, I get an error related to static link of dynamic object libltdl.so. In the make output I can see it is explicitly referring to this shared library. How can I tell it to link with libltdl.a (which is already existing) instead? Thanks, Anurag

2 1

IPV6_PKTINFO/recvfromto
by Alexander Clouter 14 Dec '10

14 Dec '10

Hi, Whilst rolling out our new FreeRADIUS infrastructure I stumbled on a Linux bug where for IPv6 clients the reply source IP address from the server does not necessary match the request's destination address; as a result the client ignores the reply packet. I use OSPF to anycast our RADIUS servers and so have to bind to '::', the box as a result is obviously multi-homed too. I am guessing this is why I am seeing the bug whilst most other (in)?sane sysadmin's bind to the EUI64 address and so do not see this problem. Turns out 'struct in6_pktinfo' is a GNU extension[1] and so you need to define _GNU_SOURCE when ./configure is running otherwise you get HAVE_IN6_PKTINFO is undefined. I just gave it a whirl, config.cache shows 'yes' now for the presence of ipi6_pktinfo: ---- ac56@domokun:/usr/src/deb-src/freeradius/freeradius-2.1.10+dfsg$ grep pktinfo config.cache ac_cv_type_struct_in6_pktinfo_has_ipi6_addr=${ac_cv_type_struct_in6_pktinfo_has_ipi6_addr=yes} ac_cv_type_struct_in_pktinfo_has_ipi_addr=${ac_cv_type_struct_in_pktinfo_has_ipi_addr=yes} ---- Until I forced _GNU_SOURCE into CFLAGS I was seeing '${ac_cv_type_struct_in6_pktinfo_has_ipi6_addr=}', note the lack of a 'yes' on the end there, which would explain why things were not behaving. Once this was enabled, I noticed that someone thinks IPv6 addresses are integers, so I have provided a patch to fix that. I noticed someone has disabled udpfromto.c being used for IPv6 sockets altogether...this is also fixed in the patch :) I would provide a patch for the autoconf bit but I have no idea how to persuade autoconf to do what I want...from what I have heard I do not want to either :) Anyway, with the following, my IPv6 client support works once again, although someone with Clue(tm) probably should look over it to make sure all is well with it :) Cheers [1] http://linux.derkeiler.com/Mailing-Lists/Fedora/2009-02/msg00318.html --- freeradius-2.1.10+dfsg.orig/src/lib/udpfromto.c 2010-09-28 11:03:56.000000000 +0000 +++ freeradius-2.1.10+dfsg/src/lib/udpfromto.c 2010-12-13 19:12:40.000000000 +0000 @@ -87,7 +87,7 @@ * This should actually be standard IPv6 */ proto = IPPROTO_IPV6; - flag = IPV6_PKTINFO; + flag = IPV6_RECVPKTINFO; #endif #endif } else { @@ -172,7 +172,7 @@ return -1; } *tolen = sizeof(*dst); - *dst = *src; + memcpy(dst, src, sizeof(*dst)); #if !defined(HAVE_IN6_PKTINFO) /* @@ -240,7 +240,7 @@ (cmsg->cmsg_type == IPV6_PKTINFO)) { struct in6_pktinfo *i = (struct in6_pktinfo *) CMSG_DATA(cmsg); - ((struct sockaddr_in6 *)to)->sin6_addr = i->ipi6_addr; + memcpy(&((struct sockaddr_in6 *) to)->sin6_addr, &i->ipi6_addr, sizeof(struct in6_addr)); *tolen = sizeof(struct sockaddr_in6); break; } @@ -335,7 +335,7 @@ pkt = (struct in6_pktinfo *) CMSG_DATA(cmsg); memset(pkt, 0, sizeof(*pkt)); - pkt->ipi6_addr = s6->sin6_addr; + memcpy(&pkt->ipi6_addr, &s6->sin6_addr, sizeof(struct in6_addr)); #endif } #endif --- freeradius-2.1.10+dfsg.orig/src/lib/radius.c 2010-09-28 11:03:56.000000000 +0000 +++ freeradius-2.1.10+dfsg/src/lib/radius.c 2010-12-13 19:11:34.000000000 +0000 @@ -228,13 +228,11 @@ #ifdef WITH_UDPFROMTO /* - * Only IPv4 is supported for udpfromto. - * * And if they don't specify a source IP address, don't * use udpfromto. */ - if ((dst_ipaddr->af == AF_INET) && - (src_ipaddr->af != AF_UNSPEC)) { + if ((dst_ipaddr->af == AF_INET || dst_ipaddr->af == AF_INET6) + && (src_ipaddr->af != AF_UNSPEC)) { return sendfromto(sockfd, data, data_len, flags, (struct sockaddr *)&src, sizeof_src, (struct sockaddr *)&dst, sizeof_dst); @@ -244,7 +242,7 @@ #endif /* - * No udpfromto, OR an IPv6 socket, fail gracefully. + * No udpfromto so fail gracefully. */ return sendto(sockfd, data, data_len, flags, (struct sockaddr *) &dst, sizeof_dst); @@ -415,14 +413,14 @@ * packet after "len" bytes. */ #ifdef WITH_UDPFROMTO - if (dst.ss_family == AF_INET) { + if (dst.ss_family == AF_INET || dst.ss_family == AF_INET6) { data_len = recvfromto(sockfd, buf, len, flags, (struct sockaddr *)&src, &sizeof_src, (struct sockaddr *)&dst, &sizeof_dst); } else #endif /* - * No udpfromto, OR an IPv6 socket. Fail gracefully. + * No udpfromto so fail gracefully. */ data_len = recvfrom(sockfd, buf, len, flags, (struct sockaddr *)&src, &sizeof_src);

2 5

LDAP + 802.1x + windows
by Nabawia Khalil 07 Dec '10

07 Dec '10

Dear All, I configured my freeradius to authenticate 802.1x from the ldap server. To authenticate the windows mschap2 I have to install securew2 client. It is hard to install securew2 on all university pcs because it needs a license per PC. Is it possible to modify the freeradius configuration to convert the MSCHAP2 password to PAP before sending it to the ldap server or doing conversion from PAP to MSCHAP2 thanks Nabawia

3 2

robust-proxy-accounting issue
by Paul Sherratt 06 Dec '10

06 Dec '10

I've just installed latest fr2.1.10 stable, and testing the stock robust-proxy-accounting. It looks as if when all home servers are down, the detail file is continuously replayed over itself, causing new attributes to be appended on each poll and rapidly increasing the size of the detail log, and other obscurities like Packet-Transmit-Counter being re-set as it thinks each re-play is a new proxied packet. In rlm_detail.c:479 if (request->listener->type == RAD_LISTEN_DETAIL && strcmp(((struct detail_instance *)instance)->detailfile, ((listen_detail_t *)request->listener->data)->filename) == 0) { RDEBUG("Suppressing writes to detail file as the request was just read from a detail file."); return RLM_MODULE_NOOP; } It looks like in the example config, detail-%Y%m%d:%H is used on the detail writer, and detail-*:* is used on the detail listener, which wont match above? So short-term workaround is to just use a single detail file. Rgds Paul --8<---------------- Going to the next request Detail listener /var/log/freeradius/radacct/detail.example.com/detail-*:* state replied signalled 0 waiting 0.005643 sec Detail - unlinking /var/log/freeradius/radacct/detail.example.com/detail.work Detail listener /var/log/freeradius/radacct/detail.example.com/detail-*:* state unopened signalled 0 waiting 1.035186 sec Waking up in 1.0 seconds. Polling for detail file /var/log/freeradius/radacct/detail.example.com/detail-*:* Detail - Renaming /var/log/freeradius/radacct/detail.example.com/detail-20101203:15 -> /var/log/freeradius/radacct/detail.example.com/detail.work detail_recv: Read packet from /var/log/freeradius/radacct/detail.example.com/detail.work Acct-Status-Type = Interim-Update NAS-IP-Address = 192.0.2.1 Realm = "acct_realm.example.com" FreeRADIUS-Proxied-To = 192.0.2.20 Packet-Original-Timestamp = "Dec 3 2010 15:14:32 GMT" Acct-Delay-Time = 21 Packet-Transmit-Counter = 1 Realm = "acct_realm.example.com" FreeRADIUS-Proxied-To = 192.0.2.10 Packet-Original-Timestamp = "Dec 3 2010 15:14:39 GMT" Realm = "acct_realm.example.com" FreeRADIUS-Proxied-To = 192.0.2.10 Packet-Original-Timestamp = "Dec 3 2010 15:14:46 GMT" server home.example.com { WARNING: Empty preacct section. Using default return values. # Executing section accounting from file /etc/freeradius/sites-enabled/test +- entering group accounting {...} ++[control] returns noop } # server home.example.com server home.example.com { WARNING: Empty pre-proxy section. Using default return values. } >>> Sending proxied request internally to virtual server. server acct_detail.example.com { WARNING: Empty preacct section. Using default return values. # Executing section accounting from file /etc/freeradius/sites-enabled/test +- entering group accounting {...} [detail.example.com] expand: /var/log/freeradius/radacct/detail.example.com/detail-%Y%m%d:%H -> /var/log/freeradius/radacct/detail.example.com/detail-20101203:15 [detail.example.com] /var/log/freeradius/radacct/detail.example.com/detail-%Y%m%d:%H expands to /var/log/freeradius/radacct/detail.example.com/detail-20101203:15 [detail.example.com] expand: %t -> Fri Dec 3 15:14:56 2010 ++[detail.example.com] returns ok } # server acct_detail.example.com Going to the next request <<< Received proxied response code 5 from internal virtual server. server home.example.com { WARNING: Empty post-proxy section. Using default return values. # Executing section post-proxy from file /etc/freeradius/sites-enabled/test } server home.example.com { } # server home.example.com Finished request 5. ... Cleaning up request 7 ID 25567 with timestamp +37 Going to the next request Detail listener /var/log/freeradius/radacct/detail.example.com/detail-*:* state replied signalled 0 waiting 0.002655 sec Detail - unlinking /var/log/freeradius/radacct/detail.example.com/detail.work Detail listener /var/log/freeradius/radacct/detail.example.com/detail-*:* state unopened signalled 0 waiting 1.146660 sec Waking up in 1.1 seconds. Polling for detail file /var/log/freeradius/radacct/detail.example.com/detail-*:* Detail - Renaming /var/log/freeradius/radacct/detail.example.com/detail-20101203:15 -> /var/log/freeradius/radacct/detail.example.com/detail.work detail_recv: Read packet from /var/log/freeradius/radacct/detail.example.com/detail.work Acct-Status-Type = Interim-Update NAS-IP-Address = 192.0.2.1 Realm = "acct_realm.example.com" FreeRADIUS-Proxied-To = 192.0.2.20 Packet-Original-Timestamp = "Dec 3 2010 15:14:32 GMT" Acct-Delay-Time = 25 Packet-Transmit-Counter = 1 Realm = "acct_realm.example.com" FreeRADIUS-Proxied-To = 192.0.2.10 Packet-Original-Timestamp = "Dec 3 2010 15:14:39 GMT" Realm = "acct_realm.example.com" FreeRADIUS-Proxied-To = 192.0.2.10 Packet-Original-Timestamp = "Dec 3 2010 15:14:46 GMT" Proxy-State = 0x3239373330 Packet-Original-Timestamp = "Dec 3 2010 15:14:53 GMT" Proxy-State = 0x3237313737 Packet-Original-Timestamp = "Dec 3 2010 15:14:55 GMT" Proxy-State = 0x3235353637 Packet-Original-Timestamp = "Dec 3 2010 15:14:56 GMT"

2 2