Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a freeradius 2.0.4 server i want to has been running without interruption for 2 years.
My update consists only in updating the chap module without creating a new one.
To avoid discontinuity of service and be sure that all configs remain the same, i am trying to find a smooth way to do that on a testing machine.
I thought it would be possible to simply replace the library with my modified version of it. but this produces a segfault (most probably caused by a library conflict).

Other information:
- Freeradius starts and segfault is produced when the chap module is call at the first request.
- My library works fine when it is used along with the compiled version from sources of freeradius
- I am using 2 versions of Freeradius: 2.0.4 installed through an apt-get install and the compiled version from apt-get sources
- The library conflict is caused by the modified library and by nothing else. If i restore the original version of (and do nothing else) it works fine again.
- I am still a noob in compilation/library manipulations/freeradius, so i'm probably doing a lot of things wrong.

Any ideas?


share|improve this question
up vote 0 down vote accepted

I'm not sure what you mean by "library conflict".

But anyway, you shouldn't do this. If you're modifying rlm_chap it must be built against the same version of the source as libfreeradius and radiusd.

If you're attempting to use a packaged version of rlm_chap from a more recent release of FreeRADIUS (say 2.2.0) it likely will not work because the internal APIs of FreeRADIUS may of changed.

With FreeRADIUS 3.0.0 this is explicitly forbidden. The server will refuse to start if it loads a module linked against a different version of the library.

It will also refuse to start if it was built with a different version of OpenSSL to the one it's linking to at runtime.

If you're set on updating rlm_chap, you will need to download the official release of 2.0.4, swap out the rlm_chap code in src/modules/rlm_chap, attempt to build the module, fix any build errors, and then use that version in place of the current .so.

share|improve this answer
I solved my problem myself but forgot to post it here, I was actually misunderstanding the difference between compiling and building from the source code. A "./configure make make install" uses different compilation options and settings than a "fakeroot dpkg-buildpackage -b -uc" as described in freeradius wiki. When building from sources, the libraries were perfectly interchangeable. Thanks anyways – ycouble May 2 '13 at 8:14
I will still mark your answer as the right one for you last paragraph. – ycouble May 2 '13 at 8:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.