new eap type
jhutz at cmu.edu
Wed Sep 3 19:52:05 CEST 2008
--On Wednesday, September 03, 2008 07:05:50 PM +0200 Terdik Sándor
<pillantok at freemail.hu> wrote:
> I would like to build in a new eap type. I made a new directory in the
> /modules/rlm_eap/types/rlm_eap_new and wrote two files: "rlm_eap_new.c"
> and "eap_new.h" . In the first file I implement the basics
> functions(initiate, authenticate etc.) and in the header the packet type
> structure. My example was the rlm_mschapv module for test. The basics
> functions are empty now. The functions have only the return value, 1 at
> present. I add the new line to eap_types.h : #define PW_EAP_NEW 50
> and modified the PW_EAP_MAX_TYPES to 50.
This isn't the direct cause of your problem, but that's a really bad idea.
EAP method type numbers are protocol constants, coordinated by the Internet
Assigned Numbers Authority (IANA). To obtain a number, you will need to
write up a specification for your method, describing what its messages are,
how they are formatted, and how the method works, and then submit an
application for protocol number assignment to IANA using the form found at
For experimentation and development, you can use method number 255, as
described in RFC3748 section 5.8.
> I rebuilt the freeradius. I modified the eap.conf:
"..." is not valid syntax here, so either your configuration is hopelessly
broken, or you've not provided nearly enough information for anyone to
explain what is going wrong. Possibly both.
> I run again the radiusd -X and I get segmentation fault message when the
> radiusd load my eap type. I don't know why!
We don't know why either, because you've provided basically no information.
My suggestion would be to find a debugger, learn how to use it, and then
use it to investigate what is going on at the time radiusd crashes.
Chances are that this will point you at the problem fairly quickly, and
that the problem will turn out to be something simple and obvious once you
find it (most bugs are). If you've never used a debugger before, I would
suggest the following:
- Run "gdb /path/to/radiusd"
- At the (gdb) prompt, type "run -X"
- At the point of failure, gdb will print something like:
Program received signal SIGSEGV, Segmentation fault.
- Type "where". The output is a description of the program's stack.
- Chances are the problem is either in the top-most function in the
list, or where one function is called by the one listed below it.
Beyond that, I can give you no advice. Debugging is a task requiring a
certain amount of skill and, often, experience, and is not something this
mailing list is set up to teach.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Carnegie Mellon University - Pittsburgh, PA
More information about the Freeradius-Devel