Re: RADIUS, EAP and FreeRADIUS presentation in French
Hi, I'm very glad you appreciate the presentation. It definitely motivates me to work on it a bit more and make it open. It was initially meant to be just a presentation for a training session, that's why it's hard to navigate right now. But I'll work on it and keep you posted. I keep saying Authentification all the time, sorry about that, I'll fix that. Cheers, Aurélien Le 8 janv. 2011 à 09:52, Alan DeKok a écrit : > Aurélien Geron wrote: >> I wrote a presentation of RADIUS, EAP and FreeRADIUS, in French, for my >> colleagues. The presentation is quite detailed, and I thought it might >> be a good introduction for anyone interested in RADIUS, EAP and FreeRADIUS. > > It's very good. > >> I used Keynotes on Mac and I exported the result to HTML (unfortunately, >> it actually produces a bunch of roughly 170kB JPEG images, I don't know >> if there is a better export solution to HTML). Here's the result: >> http://aureliengeron.free.fr/livrewifi/freeradius.html > > Better conversions should be possible. My main complaint right now is > that there's no navigation. Everything is all on one URL, with no way > to move back, or to pick a specific slide. > >> I have two questions: >> >>* is anyone interested in helping me translate it to English? I >> could try to translate about 10 slides per week in my spare time, >> but given that there are 215 slides... it will take months ! > > Yes, I think it's very useful. > >>* is there any better place you would recommend my publishing it? I >> would be happy to make it open source, should anyone else want to >> fix errors or contribute more information (I covered writing >> simple python modules, but not C modules, for example). > > We can host it on freeradius.org, if you want. If there's a good HTML > conversion, that would help, too. > >> Note: some of the diagrams are extracted from a WiFi book I wrote a few >> years back, and my publisher authorized me to publish some extracts on >> my website, but I will probably need his authorization before I can make >> those diagrams open source (I don't think he'll mind at all, though). > > OK. > > 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
RADIUS, EAP and FreeRADIUS presentation in French
Hi, I wrote a presentation of RADIUS, EAP and FreeRADIUS, in French, for my colleagues. The presentation is quite detailed, and I thought it might be a good introduction for anyone interested in RADIUS, EAP and FreeRADIUS. I used Keynotes on Mac and I exported the result to HTML (unfortunately, it actually produces a bunch of roughly 170kB JPEG images, I don't know if there is a better export solution to HTML). Here's the result: http://aureliengeron.free.fr/livrewifi/freeradius.html I have two questions: is anyone interested in helping me translate it to English? I could try to translate about 10 slides per week in my spare time, but given that there are 215 slides... it will take months ! is there any better place you would recommend my publishing it? I would be happy to make it open source, should anyone else want to fix errors or contribute more information (I covered writing simple python modules, but not C modules, for example). Note: some of the diagrams are extracted from a WiFi book I wrote a few years back, and my publisher authorized me to publish some extracts on my website, but I will probably need his authorization before I can make those diagrams open source (I don't think he'll mind at all, though). Thanks for your feedback, Aurélien Geron - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_python and dynload problem
Hi, The workaround described in http://bugs.debian.org/416266 for perl works for python too, I just tried it: LD_PRELOAD=/usr/lib/libpython2.5.so.1 freeradius -X => works fine Thanks a lot, Aurélien Geron Le 6 janv. 2011 à 14:44, Josip Rodin a écrit : > On Thu, Jan 06, 2011 at 11:26:44AM +0100, Aurélien Geron wrote: >> Hi and happy new year to everyone, >> >> In april I wrote the message below about python modules not being able to >> load dynamic libraries on Debian Lenny. > >> I did not have time to test this ever since, but I just did, and >> unfortunately, I still have the same problem on Debian Lenny, using the >> latest FreeRADIUS backport for Lenny (it is based on FreeRADIUS 2.1.10, >> the Debian package is labelled "2.1.10+dfsg-2~bpo50+1"). >> >>> - running a perfectly standard Debian Lenny (2.6.26-2-amd64) >>> - installed the latest freeradius package from the lenny-backports >>> (2.1.8+dfsg-1~bpo50+1) > > Can you verify that your exact freeradius packages used now - do indeed link > to libltdl7 and use the new code? > > Generic amd64 packages should be fine, but do check just in case... > > Perhaps also use ltrace to find the symbol lookup function used? > You need to see some lt_dladvise_*() and/or lt_dlopenadvise() mentioned. > > (Assuming the cause for this is http://bugs.debian.org/416266 ) > > -- > 2. That which causes joy or happiness. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_python and dynload problem
<... lt_dlopenext resumed> ) = 0x1d02af0 lt_dlsym(0x1d02af0, 0x7fff94d3d110, 0xfefeff646bff6d6e, 0x656d006e6f, 0xfefefefefefefeff) = 0x7f27c1f674e0 I hope this answers your questions. Thanks, Aurélien Le 6 janv. 2011 à 14:44, Josip Rodin a écrit : > On Thu, Jan 06, 2011 at 11:26:44AM +0100, Aurélien Geron wrote: >> Hi and happy new year to everyone, >> >> In april I wrote the message below about python modules not being able to >> load dynamic libraries on Debian Lenny. > >> I did not have time to test this ever since, but I just did, and >> unfortunately, I still have the same problem on Debian Lenny, using the >> latest FreeRADIUS backport for Lenny (it is based on FreeRADIUS 2.1.10, >> the Debian package is labelled "2.1.10+dfsg-2~bpo50+1"). >> >>> - running a perfectly standard Debian Lenny (2.6.26-2-amd64) >>> - installed the latest freeradius package from the lenny-backports >>> (2.1.8+dfsg-1~bpo50+1) > > Can you verify that your exact freeradius packages used now - do indeed link > to libltdl7 and use the new code? > > Generic amd64 packages should be fine, but do check just in case... > > Perhaps also use ltrace to find the symbol lookup function used? > You need to see some lt_dladvise_*() and/or lt_dlopenadvise() mentioned. > > (Assuming the cause for this is http://bugs.debian.org/416266 ) > > -- > 2. That which causes joy or happiness. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_python and dynload problem
Hi and happy new year to everyone,
In april I wrote the message below about python modules not being able to load
dynamic libraries on Debian Lenny. Alan DeKok answered that he would try to
fix this in version 2.1.9, and I was very pleased to read the following message
in version 2.1.9's Changelog:
"Update configure script for rlm_python to avoid dynamic linking problems on
some platforms."
I did not have time to test this ever since, but I just did, and unfortunately,
I still have the same problem on Debian Lenny, using the latest FreeRADIUS
backport for Lenny (it is based on FreeRADIUS 2.1.10, the Debian package is
labelled "2.1.10+dfsg-2~bpo50+1"). Is this a problem that I should report to
the package's maintainer for Debian (did he forget some compilation option?),
or is it something that should be fixed within FreeRADIUS itself?
Here's FreeRADIUS's debug output:
[...]
Module: Linked to module rlm_python
Module: Instantiating module "python_test" from file
/etc/freeradius/modules/python
python_init done
python python_test {
mod_instantiate = "test_freeradius"
func_instantiate = "instantiate"
mod_authorize = "test_freeradius"
func_authorize = "authorize"
mod_authenticate = "test_freeradius"
func_authenticate = "authenticate"
mod_accounting = "test_freeradius"
func_accounting = "accounting"
mod_checksimul = "test_freeradius"
func_checksimul = "checksimul"
mod_pre_proxy = "test_freeradius"
func_pre_proxy = "pre_proxy"
mod_post_proxy = "test_freeradius"
func_post_proxy = "post_proxy"
mod_post_auth = "test_freeradius"
func_post_auth = "post_auth"
mod_recv_coa = "test_freeradius"
func_recv_coa = "recv_coa"
mod_send_coa = "test_freeradius"
func_send_coa = "send_coa"
mod_detach = "test_freeradius"
func_detach = "detach"
}
rlm_python:python_load_function: module 'test_freeradius' is not found
rlm_python:EXCEPT::
/usr/lib/python2.5/lib-dynload/math.so: undefined symbol: PyExc_ValueError
rlm_python:python_load_function: failed to import python function
'test_freeradius.instantiate'
/etc/freeradius/modules/python[69]: Instantiation failed for module
"python_test"
/etc/freeradius/sites-enabled/default[205]: Failed to load module "python_test".
/etc/freeradius/sites-enabled/default[62]: Errors parsing authorize section.
The python code looks like this:
import radiusd
import math
def get_radius_attribute(attribute, p):
for attr, val in p:
if attr==attribute:
return val
def instantiate(p):
radiusd.radlog(radiusd.L_DBG, '*** python: instantiate ***')
return radiusd.RLM_MODULE_OK
[...] # all other functions are exactly similar
Everything works fine if I just remove the line "import math".
Thank you very much for your help,
Aurélien Geron
Le 27 avr. 2010 à 01:56, Aurélien Geron a écrit :
> Hi,
>
> I came across a bug when rlm_python executes python code that tries to load a
> dynamic (shared) module. This bug seems to have been discussed 2 or 3 times
> on this list, but no really satisfying solution appears to have been found so
> far (as far as I know), so I thought I might raise the subject again and
> perhaps try to contribute in finding a solution.
>
> In short, I think the solution to this problem is explained here, but I don't
> know how to implement it in freeRADIUS :
> http://docs.python.org/release/2.5.2/ext/link-reqs.html
>
> Here is my setup :
> - running a perfectly standard Debian Lenny (2.6.26-2-amd64)
> - installed the latest freeradius package from the lenny-backports
> (2.1.8+dfsg-1~bpo50+1)
> - the python debian package is the one installed with Debian Lenny (2.5.2-3)
>
> Here is my config:
>
> --
> ###
> # /etc/freeradius/modules/python
> ###
> python python_test {
> mod_instantiate = radiusd_test
> func_instantiate = instantiate
> }
>
> ###
> # /etc/freeradius/radiusd.conf
> ###
> ...
> instantiate {
>python_test
> }
> ...
>
> ###
> # /usr/lib/python2.5/site-packages/radiusd_test.py
> ###
> def instantiate(p):
>radiusd.radlog(radiusd.L_DBG, "THIS WORKS")
>import random # this crashes
>radiusd.radlog(radiusd.L_DBG, "THIS IS NEVER REACHED !")
> --
>
> Here is the output of "freeradius -X" :
>
> --
Re: supplicant winxp+freeradius+ldap
John Dennis wrote: > On 04/30/2010 02:50 AM, Daniel Soto wrote: >> hi. >> >> i think that this problem is very similar to many people but i can´t >> find the solution. >> >> i´m trying authenticate users of windows with is own supplicant, when i >> try authenticate in local users no problem, however the problem is when >> i try it with openldap. >> >> i received a message. >> >> Auth: rlm_ldap: Attribute "User-Password" is required for authentication. >> Thu Apr 29 16:44:57 2010 : Auth: Login incorrect: [peter] (from client >> wifi port 6145 cli 00-74-05-A6-91-BD) >> >> i have read most about this problem but i can´t find de solution. > > If your debug output (which you didn't provide) contains this line: > > WARNING: No "known good" password was found in LDAP. Are you sure that the > user is configured correctly? > > Then the likely problem is this line is missing from /etc/raddb/ldap.attrmap > > checkItem Cleartext-Password userPassword > > Here is what might be going on: > > Many authentication protocols (i.e. mschap) require that a clear text > password be available to the radius server. Hopefully you have set the > userPassword attribute for your users in your ldap server and protected it > with an ACL. rlm_ldap will lookup the user in ldap and requests the > attributes defined in /etc/raddb/ldap.attrmap labeled "checkItem" and then > adds those attributes it found to the request. The attribute retrieved from > ldap is the 3rd item on the line, the radius attribute which is added to the > request is the 2nd item on the line. Thus what the above does is to add > Cleartext-Password as a radius check item to the request with the value of > the ldap attribute userPassword for the user. > > For reasons I do not understand the above line is missing from the default > ldap.attrmap and this has tripped numerous people up. > > Alan: Is there a reason why ldap.attrmap omits the clear text password > retrieval? I think you can safely ignore this warning, if authentication works. For example, I have PEAP/MS-CHAP-v2 setup, and FreeRADIUS queries my LDAP server and retrieves the ntPassword LDAP attribute. I do not use CHAP or PAP or any authentication method other than PEAP/MS-CHAP-v2, so I actually do *not* need to store the user's clear text password in the LDAP server... therefore I don't. I think I could remove the "checkitem Cleartext-Password userPassword" line in ldap.attrmap, and everything would still run fine. So I just ignore the "No "known good" password" warning. I haven't tried, but maybe if I set "password_attribute = ntPassword" in modules/ldap, it might remove the warning. You may want to try that ? Aurélien Geron - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_python and dynload problem
Alan DeKok wrote: > Aurélien Geron wrote: >> Basically, if I understand correctly, his idea is to have the python fellows >> declare the proper dependencies in every *.so file, so that the >> libpython2.5.so.1 file gets loaded automatically when the "math" module (or >> any other dynamic module) gets loaded. Maybe that's the ideal solution, I >> really don't know. But it seems to me that we should try to fix freeRADIUS >> so that it works around this bug before python dependencies are fixed (it >> make take a while or even never happen). So I thing the only >> short-medium-term solution is to use LINKFORSHARED linker options. >> >> Thanks for reading this huge message. I hope we can beat this bug. > > OK. I'll see about putting that fix into 2.1.9. > > Alan DeKok. That's great, thanks a lot Alan. If I can be of any help (for example, for testing), please let me know. Aurélien Geron - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_python and dynload problem
Hi,
I came across a bug when rlm_python executes python code that tries to load a
dynamic (shared) module. This bug seems to have been discussed 2 or 3 times on
this list, but no really satisfying solution appears to have been found so far
(as far as I know), so I thought I might raise the subject again and perhaps
try to contribute in finding a solution.
In short, I think the solution to this problem is explained here, but I don't
know how to implement it in freeRADIUS :
http://docs.python.org/release/2.5.2/ext/link-reqs.html
Here is my setup :
- running a perfectly standard Debian Lenny (2.6.26-2-amd64)
- installed the latest freeradius package from the lenny-backports
(2.1.8+dfsg-1~bpo50+1)
- the python debian package is the one installed with Debian Lenny (2.5.2-3)
Here is my config:
--
###
# /etc/freeradius/modules/python
###
python python_test {
mod_instantiate = radiusd_test
func_instantiate = instantiate
}
###
# /etc/freeradius/radiusd.conf
###
...
instantiate {
python_test
}
...
###
# /usr/lib/python2.5/site-packages/radiusd_test.py
###
def instantiate(p):
radiusd.radlog(radiusd.L_DBG, "THIS WORKS")
import random # this crashes
radiusd.radlog(radiusd.L_DBG, "THIS IS NEVER REACHED !")
--
Here is the output of "freeradius -X" :
--
FreeRADIUS Version 2.1.8, for host x86_64-pc-linux-gnu, built on Apr 26 2010 at
21:49:28
Copyright (C) 1999-2009 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License v2.
Starting - reading configuration files ...
including configuration file /etc/freeradius/radiusd.conf
...
Module: Linked to module rlm_python
Module: Instantiating python_test
python_init done
python python_test {
mod_instantiate = "radiusd_test"
func_instantiate = "instantiate"
}
THIS WORKS
rlm_python:EXCEPT::
/usr/lib/python2.5/lib-dynload/math.so: undefined symbol: PyExc_ValueError
/etc/freeradius/modules/python[24]: Instantiation failed for module
"python_test"
--
The module is properly loaded, the "instantiate" function gets called, and the
first log message is output. In fact, any 100% pure python code works fine.
The bug happens when a python module gets loaded dynamically : importing any
module located in /usr/lib/python2.5/lib-dynload/*.so will crash.
>From what I understand, here's what happens:
1) rlm_python was built against libpython2.5.a, but for optimization purposes,
the linker stripped out all the symbols that were not used by rlm_python itself
(including, for example, PyExc_ValueError). This behavior is
platform-dependent, which probably explains why everything works fine on
centos, for example.
2) when the radiusd_test module runs, it tries to import the "random" module,
which itself tries to import the "math" module, which is in lib-dynload, and
gets loaded dynamically.
3) unfortunately, python fails to load that module because it uses the
PyExc_ValueError symbol and it does not know where it is defined (it is located
in /usr/lib/libpython2.5.so.1, but unfortunately, the "math" module does not
know that.
As I said, I believe that the solution to this problem is clearly explained
here: http://docs.python.org/release/2.5.2/ext/link-reqs.html
As it's just a few paragraphs, I'll quote it here, for your convenience:
--
While the configure script shipped with the Python sources will correctly build
Python to export the symbols needed by dynamically linked extensions, this is
not automatically inherited by applications which embed the Python library
statically, at least on Unix. This is an issue when the application is linked
to the static runtime library (libpython.a) and needs to load dynamic
extensions (implemented as.so files).
The problem is that some entry points are defined by the Python runtime solely
for extension modules to use. If the embedding application does not use any of
these entry points, some linkers will not include those entries in the symbol
table of the finished executable. Some additional options are needed to inform
the linker not to remove these symbols.
Determining the right options to use for any given platform can be quite
difficult, but fortunately the Python configuration already has those values.
To retrieve them from an installed Python interpreter, start an interactive
interpreter and have a short session like this:
>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('LINKFORSHARED')
'-Xlinker -export-dynamic'
The contents of the string presented will be the options that should be used.
If the string is empty, there's no need to add
