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

rlm_sql_ocioracle driver v. 0.1
by Ge＠＠ru 14 Mar '15

14 Mar '15

Hi, in attachment patch to add rlm_sql_ocioracle driver to freeradius 2.1.x tree (it seems work yet on 3.x tree). This drivers permit to use function/procedure with CURSOR (through :Ret_Cursor string) like for example: group_membership_query = "begin :Ret_Cursor := \ pkRadius.group_membership_query('%{SQL-User-Name}'); end;" TODO for next release: - add support to oracle connection pool instead of open a new connection for every socket on startup; - enhancement on handle error (through error callback) on do query; - add documentation. Module need oracle instantclient library and ocilib library (http://orclib.sourceforge.net/) Good luck to rlm_sql_ocioracle driver!! Geaaru

2 5

Re: FR3 HEAD/MASTER segmentation fault
by Alan Buxey 22 Jan '13

22 Jan '13

It's a full production server, a stripped down config wouldn't be useful....however I might be able to spin one up with minimal config for some dedicated local usage. I *believe* that its the proxying of a request to a remote target using the TLS proxy (which could be over ipv6 or ipv4) that exhibits this.....I guess I could verify this by disabling the TLS proxy function ..... alan

4 3

FR3 segfault (continued...)
by Alan Buxey 21 Jan '13

21 Jan '13

hi, ..still on the path of the cause of the segfault. I put a suspicion on the TLS code feature new in 3.x - so disabled the virtual server that does TLS proxying....and just went to old school RADIUS for remote proxying.... the bad news is that there was still a segfault...the good news , I guess, is that without the TLS module, the server can run with -X - and therefore single threaded....so the cause of the crash might be slightly less opaque - have uploaded the relevant GDB output etc to bugs.freeradius.org (did find another fault too....is triggered in a different code path...in EAP section it seems....not related to the usual pre_proxy to proxy handling....have uploaded the relevant GDB of that too - bugs.freeradius.org) ...wont be long until we've squished these show stoppers. alan

3 3

New build system
by Alan DeKok 21 Jan '13

21 Jan '13

After a few days of banging on it, it seems to work. I've just committed a few changes to address the last few problems. A "make -j 8" now works, with the new boilermake. All dependencies are tracked. Some of the dependencies aren't perfect, but they work. If there are no cries of pain, we'll spend the next few days deleting the old build system. Alan DeKok.

2 2

New LDAP module in "master"
by Alan DeKok 21 Jan '13

21 Jan '13

I've re-written the LDAP module in "master". The code is simpler, cleaner, and easier to understand. It is largely compatible in function with the old module, with the following differences: - the eDirectory code has been removed. I don't run eDir, and I can't test it. Patches to re-add it are welcome - the module uses the new connection pool API. As a result, its configuration is more in line with the rest of the server - the config items have been reorganized to make more sense. The names are similar, but they're grouped into sections I've tested it against a number of LDAP servers. It seems to be stable, and performs at 6K queries per second in sustained load. The old module was much less than that. The new connection pool also means that the module can re-use connections in more situations. Previously, the module would close and then re-open connections many times. Now, it does so much less often. The next steps are: - add eDir support (if people need it) - move "ldap.attrmap" to the module configuration. Alan DeKok.

3 5

Proxy fixes
by Alan DeKok 08 Jan '13

08 Jan '13

I managed to find an hour or two in between various things. I've taken a look at the proxy code, and added some fixes in "master". To be polite, I didn't quite understand the previous code. So... I've deleted things, and simplified other things. The result is that the "zombie" home server detection should be better. I don't know if it fixes the "crash on dead home server" issue that people were seeing. I wasn't able to reproduce that. But, the relevant code is now different. So I hope it's fixed. As always, blame Arran for any bugs. :) Alan DeKok.

3 8

Commit report for master branch
by announce＠freeradius.org 31 Dec '12

31 Dec '12

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Minor fixes in rlm_rest Arran Cudbard-Bell@2012-12-31T12:36:35Z Files modified: * src/modules/rlm_rest/rest.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/3196677cd02ed419f94e… ====== Update doxygen documentation Arran Cudbard-Bell@2012-12-31T01:09:43Z Files modified: * doc/source/extra/toc.c * src/lib/valuepair.c * src/main/valuepair.c * src/main/xlat.c * src/modules/rlm_rest/rest.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/45607c9c0eba9059114a… ====== initial support for multi-valued attributes in rlm_cache Olivier Beytrison (via Arran Cudbard-Bell)@2012-12-30T18:03:12Z Files modified: * src/modules/rlm_cache/rlm_cache.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/380e382919462385972d… ====== -- This commit summary was generated @2013-01-01T00:00:01Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for master branch
by announce＠freeradius.org 30 Dec '12

30 Dec '12

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Fix warning Arran Cudbard-Bell@2012-12-30T13:38:03Z Files modified: * src/main/connection.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/b85c3a3ff5198948b150… ====== Add support for tags to remaining functions in lib/valuepair.c Arran Cudbard-Bell@2012-12-30T13:34:27Z Files modified: * src/include/libradius.h * src/lib/dhcp.c * src/lib/radius.c * src/lib/valuepair.c * src/lib/vqp.c * src/main/acct.c * src/main/auth.c * src/main/client.c * src/main/detail.c * src/main/dhcpd.c * src/main/listen.c * src/main/modcall.c * src/main/process.c * src/main/radclient.c * src/main/realms.c * src/main/stats.c * src/main/tls.c * src/main/valuepair.c * src/main/xlat.c * src/modules/rlm_acctlog/rlm_acctlog.c * src/modules/rlm_attr_filter/rlm_attr_filter.c * src/modules/rlm_attr_rewrite/rlm_attr_rewrite.c * src/modules/rlm_cache/rlm_cache.c * src/modules/rlm_chap/rlm_chap.c * src/modules/rlm_checkval/rlm_checkval.c * src/modules/rlm_counter/rlm_counter.c * src/modules/rlm_cram/rlm_cram.c * src/modules/rlm_dbm/rlm_dbm.c * src/modules/rlm_digest/rlm_digest.c * src/modules/rlm_eap/eap.c * src/modules/rlm_eap/libeap/eapcommon.c * src/modules/rlm_eap/libeap/eapsimlib.c * src/modules/rlm_eap/mem.c * src/modules/rlm_eap/radeapclient.c * src/modules/rlm_eap/rlm_eap.c * src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c * src/modules/rlm_eap/types/rlm_eap_ikev2/ike_conf.c * src/modules/rlm_eap/types/rlm_eap_leap/rlm_eap_leap.c * src/modules/rlm_eap/types/rlm_eap_md5/rlm_eap_md5.c * src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c * src/modules/rlm_eap/types/rlm_eap_peap/peap.c * src/modules/rlm_eap/types/rlm_eap_peap/rlm_eap_peap.c * src/modules/rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.c * src/modules/rlm_eap/types/rlm_eap_sim/rlm_eap_sim.c * src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c * src/modules/rlm_eap/types/rlm_eap_tnc/rlm_eap_tnc.c * src/modules/rlm_eap/types/rlm_eap_ttls/rlm_eap_ttls.c * src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c * src/modules/rlm_eap2/rlm_eap2.c * src/modules/rlm_example/rlm_example.c * src/modules/rlm_exec/rlm_exec.c * src/modules/rlm_expiration/rlm_expiration.c * src/modules/rlm_expr/paircmp.c * src/modules/rlm_fastusers/rlm_fastusers.c * src/modules/rlm_files/rlm_files.c * src/modules/rlm_ippool/rlm_ippool.c * src/modules/rlm_jradius/rlm_jradius.c * src/modules/rlm_ldap/rlm_ldap.c * src/modules/rlm_logintime/rlm_logintime.c * src/modules/rlm_mschap/opendir.c * src/modules/rlm_mschap/rlm_mschap.c * src/modules/rlm_opendirectory/rlm_opendirectory.c * src/modules/rlm_otp/otp_mppe.c * src/modules/rlm_otp/otp_pw_valid.c * src/modules/rlm_otp/otp_pwe.c * src/modules/rlm_otp/rlm_otp.c * src/modules/rlm_pam/rlm_pam.c * src/modules/rlm_pap/rlm_pap.c * src/modules/rlm_passwd/rlm_passwd.c * src/modules/rlm_perl/rlm_perl.c * src/modules/rlm_policy/evaluate.c * src/modules/rlm_preprocess/rlm_preprocess.c * src/modules/rlm_radutmp/rlm_radutmp.c * src/modules/rlm_radutmp/rlm_radutmp2.c * src/modules/rlm_realm/rlm_realm.c * src/modules/rlm_rediswho/rlm_rediswho.c * src/modules/rlm_replicate/rlm_replicate.c * src/modules/rlm_securid/mem.c * src/modules/rlm_smsotp/rlm_smsotp.c * src/modules/rlm_soh/rlm_soh.c * src/modules/rlm_sometimes/rlm_sometimes.c * src/modules/rlm_sql/rlm_sql.c * src/modules/rlm_sqlcounter/rlm_sqlcounter.c * src/modules/rlm_sqlhpwippool/rlm_sqlhpwippool.c * src/modules/rlm_sqlippool/rlm_sqlippool.c * src/modules/rlm_unix/rlm_unix.c * src/modules/rlm_wimax/rlm_wimax.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/15cf459a4e88bbd8d9e6… ====== -- This commit summary was generated @2012-12-31T00:00:01Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Support for multi-valued attributes in rlm_cache
by Olivier Beytrison 30 Dec '12

30 Dec '12

Hi, I've been working the past days on adding support for multi-valued attributes in rlm_cache. Before I send a pull request, I'll be glad if you could review my work and report if I need to correct anything. What's currently supported : attr <op> 'string value' attr <op> "xlat expanded value" attr :=|+= attr-name Code available here : https://github.com/olivierbeytrison/freeradius-server/tree/rlm_cache-update I also wanted to know if it is "allowed" to have multiple identical attributes with the SET operator in a list. When are enforced the logic behind the operators ? when the radius packet is being crafted ? Regards, Olivier B -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier(a)heliosnet.org

2 1

Problems decoding a vendor-specified attribute on the client side
by JCA 27 Dec '12

27 Dec '12

I already sent this but forgot to include a subject line - and Gmail couldn't be bothered to remind me :-( Here it is again. I have a FreeRADIUS server 2.2.0 on a Linux box A, and a RADIUS client on a different Linux box B. The client in B has been constructed using as a basis one of the examples distributed with the FreeRADIUS 1.1.6 client code. The client uses the RADIUS library distributed with this code. Things seem to work fine, in that I can carry out authentications on A on behalf of B all right. I am having problems when trying to decode on B a vendor-specific attribute sent by A. Initially I had my users defined in /etc/freeradius/users in A along the following lines: user1 User-Password != "User1Password" user1 Cleartext-Password := "User1Password" Reply-Message = "Authentication successful." With this, the string associated with the Reply-Message attribute is sent by the server only when the authentication succeeds. On the FreeRADIUS 1.1.6 client the rc_send_server() function detects that the response payload contains more information than just the authentication diagnostic, and proceeds to decode it by invoking rc_avpair_gen(), which in turn recognizes the Reply-Message attribute identifier and the associated string value without any problems. I would like to be able to use a vendor-specified attribute, rather than Reply-Message, and to that end I added the following entry to the dictionary files in both client and server: VENDOR MyVendorID 29688 BEGIN-VENDOR MyVendorID ATTRIBUTE Vendor-Attr 1 string END-VENDOR MyVendorID (the vendor ID used here is bogus.) I also changed my users on the server as follows: user1 User-Password != "User1Password" user1 Cleartext-Password := "User1Password" Vendor-Attr = "Authentication successful." After launching the server on A again, and attempting an authentication from B, debugging the client on B reveals that the server is indeed sending the Vendor-Attr attribute with the value specified in the users file. The rc_avpair_gen() function in the client code on B detects a vendor-specified attribute, and after properly identifying it as MyVendorID it attempts to decode the attribute that follows by recursively invoking itself. In more detail: The first few bytes of the data received from the server is 0x1a 0x1b 0x00 0x00 0x73 0xf8 0x01 0x15 rc_avpair_gen() correctly identifies that this is a vendor-specified attribute (byte 0x1a) and then extracts the vendor ID itself (bytes 0x73 0xf8, or 29688 in decimal.) After verifying that this is a vendor ID that it knows about, rc_avpair_gen() invokes itself recursively on the input data offset by 7 bytes (i.e. starting at the 0x01 byte that follows the 0xf8 byte) and with the 29688 vendor ID already retrieved. rc_avpair_gen() then executes the following line: attribute = ptr[0] | (vendorpec << 16) where ptr[0] is 0x01, and vendorpec is 0x73f8. After this, attribute takes the value 0x73f80001. The code then proceeds to invoking rc_dict_getattr() in order to get the attribute, using as arguments the dictionary data previously loaded when launching the client, plus the value of the attribute variable obtained above. rc_dict_getattr() will just loop over all entries in the dictionary data, trying to find a match. This is a very simple function: DICT_ATTR *rc_dict_getattr (const rc_handle *rh, int attribute) { DICT_ATTR *attr; attr = rh->dictionary_attributes; while (attr != NULL) { if (attr->value == attribute) { return attr; } attr = attr->next; } return NULL; } Now the attr entry for the matching attribute is $53 = {name = "Vendor-Attr", '\000' <repeats 19 times>, value = 1, type = 0, next = 0x804bc90} as obtained with gdb. The comparison in the loop above will not succeed, because attr->value is 1, whereas attribute is 0x73f80001. Therefore no match will be found, and rc_dict_getattr() will return a NULL pointer, thus causing rc_avpair_gen() to generate an error message as follows: received unknown VSA attribute 1, vendor 29688 of length xx where xx is the length of the "Authentication successful." string. Thus, it would seem that the data was received correctly, but can't somehow be decoded. Notice that fudging things with gdb so that the value of attribute is set to what it should be (1) also does not work, for in that case the attribute is identified as a User-Name, instead of the vendor-specific attribute Vendor-Attr. Anybody know what is going on here? I would be tempted to say that the rc_dict_getattr() implementation is wrong, but I find it difficult to believe that it is THAT wrong - this wouldn't be just a bug, but a huge implementation error. Therefore, I must be doing something wrong myself instead. But, what? How do I define my simple vendor-specific attribute so that rc_get_attr() can identify and decode it correctly?

2 4