hi > Yes, the EAP document with the FreeRADIUS 0.7 tar ball indicates that > OpenSSL 0.9.6b or later (for example, 0.9.6c - 0.9.6g) should work. > Others were having problems with that release, so I tried it, verified > that it didn't work, tried to find out why it doesn't work (rlm needs > more recent function calls), and found a version that definitely does > work. I'm not saying I figured something out that nobody else new, > heck, I already new it and was using 0.9.7 snapshots on other machines.
ok, i wasn't trying to say that what you did was useless or something. i wanted to clarify things. for my own case, i always just took the newest openssl and it always worked (it was always the most recent 0.9.7) - since march or so... it's good to know exactly, so thanks for the clarification. > In any event, the configure routines should indicate which version is > needed, and if it is not found, that should be reported as well. > Otherwise, wrt to this module anyway, what's the point? the point is not what they should do. i asked if they did because i tend to think that they don't. > What I didn't figure out, is why, even if configure succeeds, make did > not fail when it tried to compile code referencing functions that did > not exists in any of the include files? did you try it out personally? i somehow understood that Alan and you were talking about somebody else's tries. in that case, as i tried to explain, he could have been using a module which was not compiled with the server but before, in some earlier compilation. in my case, configure NEVER succeds simply because you need a -lcrypto after the -lssl in the makefile (took some time to find this one out)... i.e. the rlm_eap_tls is never compiled if i only do "./configure"... i should try the 0.8 release, perhaps monday, i'm not in the office right now. ciao artur -- artur not at work - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
