tonimanel wrote:
Yes, but I want to say that only writes in detail_file (second detail file) when it's launch without -n radrelay option, when it should writes in detail_file (second detail file) with or without -n option, I think.
No. You don't understand what "-n" means. It's documented. "-n" means load a COMPLETELY DIFFERENT configuration. You seem to think that there's one "radiusd" process, and it magically knows everything, even when you point it at a different configuration file.
- I have tested both freeradius servers and both work fine when work individually. The first freeradius server writes in second_detail file, and second freeradius server doesn't writes in second_detail file because it is not configured (correct!). Both servers work fine with authentication and accounting processes.
OK...
- When I launch first freeradius server with -X -n radrelay options, radrelay reads from second_detail file (that exists) and send records to second freeradius server. The second freeradius server writes records in radacct table (database). Then, first freeradius server delete the second_detail file.
OK...
- When I try to authenticate to first freeradius server I get a timeout message.
Nonsense. The debug log you posted shows it sending an Access-Accept.
- The service is continuing trying to read from second_detail file (that not exists because was deleted by first freeradius service) and it's ignoring all authentication requests (in output result not appears nothing about authentication requests).
Because you told it to ignore authentication packets. Again, the debug output shows this. Honestly, I don't see what the problem is. You've been doing enormous amounts of work to try to solve the problem. It should really be about 15 minutes to follow the documentations and the messages on this list.
At the end, first freeradius server says: violation of the segment
Not in any debug output you posted.
Would you need the configuration files?
No.
If yuo need any thing else, please tell me.
We need you to read the debug output, and the messages on this list. Alan DeKok.