freeradius: failed linking to rlm_eap2
hi, I'have tried to configure eap-psk on freeradius-server v2.1.x (http://git.freeradius.org/). I have used this hostap version to have libeap.so (git clone git://w1.fi/srv/git/hostap-06.git). I followed the steps below for the compilation of freeradius: I edited the rlm_eap2/Makefile and indicates the hostapd path and the target. # ./configure --with-experimental-modules --with-rlm_eap2 # make and make install does not provide errors I commented all the line of eap.conf and add the end : eap2{ psk{} } I replaced allow eap in the site-enabled/default by eap2. when I want to start my server with this command : export LD_PRELOAD=~/eap_example/libeap.so && radiusd -x I got this message error: /usr/local/etc/raddb/eap.conf[17]: Failed linking to rlm_eap2 structure: /usr/local/lib/rlm_eap2-2.2.0.so: undefined symbol: rlm_eap2 /usr/local/etc/raddb/sites-enabled/default[310]: Failed to find "eap2" in the "modules" section. /usr/local/etc/raddb/sites-enabled/default[252]: Errors parsing authenticate section. Does any one have any ideas on how to resolve this problem? Thanks in advance.
On 09/17/2012 01:34 PM, Tatiana DIBANDA wrote:
hi, I'have tried to configure eap-psk on freeradius-server v2.1.x
This seems to come up every now and then. Obviously people need something that's in rlm_eap2 that isn't in rlm_eap. Can you explain why you need EAP-PSK? It seems to me that the rlm_eap2 code (which is clearly marked as experimental) isn't used a lot, and thus might not compile easily in all cases. If you want to step up, I'm sure help would be appreciated. Better would be to understand what people need it for, and port the code to native FreeRADIUS code. EAP-PSK doesn't look terribly hard (unlike EAP-FAST or EAP-TEAP which have rather overloaded the donkey) so if it's useful for something, maybe I'll have a go at implementing it.
Phil Mayers wrote:
This seems to come up every now and then. Obviously people need something that's in rlm_eap2 that isn't in rlm_eap.
Yeah. I would *hope* that people using experimental features know about "compilers" and "linkers". But I guess that's too much to ask.
Better would be to understand what people need it for, and port the code to native FreeRADIUS code.
Yeah.
EAP-PSK doesn't look terribly hard (unlike EAP-FAST or EAP-TEAP which have rather overloaded the donkey) so if it's useful for something, maybe I'll have a go at implementing it.
Sounds good to me. Alan DeKok.
On 09/17/2012 06:30 PM, alan buxey wrote:
Hi,
EAP-PSK doesn't look terribly hard (unlike EAP-FAST or EAP-TEAP which
TEAP is the way forward though...its the ONLY future IETF tunneled EAP method :-)
http://xkcd.com/927/ ...nicely summarises my thinking on the matter. It has has a few small advantages. None are compelling to me, and I think I'm pretty typical. Why would someone in my position move away from TEAP? More to the point, why would someone in my position spend hundreds of man-hours deciphering the TEAP RFC and writing the code, when it's notably more complex than PEAP for little gain?
On Mon, 2012-09-17 at 19:40 +0100, Phil Mayers wrote: [...]
...nicely summarises my thinking on the matter.
It has has a few small advantages. None are compelling to me, and I think I'm pretty typical. Why would someone in my position move away from TEAP?
More to the point, why would someone in my position spend hundreds of man-hours deciphering the TEAP RFC and writing the code, when it's notably more complex than PEAP for little gain?
http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 says that TEAP is "based on EAP-FAST [RFC4851] with some minor changes", of which you can find implementations around -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
On 09/17/2012 07:53 PM, Stelian Ionescu wrote:
http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 says that TEAP is "based on EAP-FAST [RFC4851] with some minor changes", of which you can find implementations around
Thanks, but you're not telling me anything I didn't already know. I'm sure someone will eventually implement TEAP for FR. My point was that: a) OP wanted EAP-PSK b) EAP-PSK is relatively simple to implement c) OP did NOT want EAP-TEAP d) EAP-TEAP is not simple to implement
Phil Mayers wrote:
It has has a few small advantages. None are compelling to me, and I think I'm pretty typical. Why would someone in my position move away from TEAP?
<la la la la happiness unicorns rainbows>
More to the point, why would someone in my position spend hundreds of man-hours deciphering the TEAP RFC and writing the code, when it's notably more complex than PEAP for little gain?
Uh... "just 'cause" ? Alan DeKok.
hi, with old config method (static) ./configure --prefix=/usr --enable-static --with-large-files --with-raddbdir=/etc/raddb --with-experimental-modules -enable-developer /etc/raddb/mods-enabled/perl[7]: Failed to link to module 'rlm_perl': /usr/lib/rlm_perl.so: undefined symbol: boot_DynaLoader /etc/raddb/sites-enabled/default[614]: Failed to find "perl" in the "modules" section. /etc/raddb/sites-enabled/default[582]: Errors parsing post-auth section. however, I saw a post today saying that static is going way of dodo along with libtool etc...so compiled without static: ./configure --prefix=/usr --with-large-files --with-raddbdir=/etc/raddb --with-experimental-modules -enable-developer /etc/raddb/mods-enabled/perl[7]: Failed to link to module 'rlm_perl': /usr/lib/rlm_perl.so: undefined symbol: boot_DynaLoader /etc/raddb/sites-enabled/default[614]: Failed to find "perl" in the "modules" section. /etc/raddb/sites-enabled/default[582]: Errors parsing post-auth section. from a quick look this appears to be an XS problem and how the .so files are loaded in with dlopen - RTLD_GLOBAL ?? alan
participants (5)
-
alan buxey -
Alan DeKok -
Phil Mayers -
Stelian Ionescu -
Tatiana DIBANDA