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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
