On Mar 6, 2008, at 12:16 AM, Alan DeKok wrote:
Zach Lowry wrote:
I think I may have gotten a little bit closer to uncovering my problem. I installed FreeRadius 1.1.7 on a FreeBSD SPARC64 machine, and got some debugging output. I then tried it again on my OpenBSD SPARC64 machine with the debugging turned all the way up: ... ldap_connect_timeout: fd: 7 tm: 4294967296 async: 0 ^^^^^^^^^^ What is this doing here?
That looks like "now", in time_t format. It may have been taken from the wrong thing, tho...
It's actually 2^32. Since I can accurately set the time to -1 or 0, I believe that the bug is coming from one library writing a 64-bit value and another reading it as a 32-bit integer.
Could this be a 64-bit portability issue in rlm_ldap?
Likely. See "net_timeout" in the CONF_PARSER module_config structure. It's parsing integers into a "tv_sec", which is type time_t. The data should really be parsed into an "int" type, and that later assigned to a tv_sec.
OK, hardcoding values fixes it. Like this: if (ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, 10) != LDAP_OPT_SUCCESS) { radlog(L_ERR, "rlm_ldap: Could not set LDAP_OPT_NETWORK_TIMEOUT %ld.%ld", inst->net_timeout.tv_sec, inst-
net_timeou t.tv_usec); } if (ldap_set_option(ld, LDAP_OPT_TIMELIMIT, 10) != LDAP_OPT_SUCCESS) { radlog(L_ERR, "rlm_ldap: Could not set LDAP_OPT_TIMELIMIT %d", inst->timelimit); }
I'll work on a better long-term solution.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html