--On Wednesday, September 03, 2008 07:05:50 PM +0200 Terdik Sándor <pillantok@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+@cmu.edu> Carnegie Mellon University - Pittsburgh, PA