new eap type

[Jeffrey Hutzelman]

--On Wednesday, September 03, 2008 07:05:50 PM +0200 Terdik Sándor 
<pillantok at freemail.hu> wrote:

>
>
> Hi!
>
> 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 
<http://www.iana.org/cgi-bin/assignments.pl>.

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:
> eap{
> ...
> md5{
> }
> ...
> new{
> }
> ...
> }

"..." 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