Migration from radsecproxy/RadSec problems

[JB]

Alan DeKok wrote:
> JB wrote:
>> The first being that FR doesn't seem to send any replies to the client when it receives Access-Request messages via RadSec.
>> At least we're not seeing the typical "Sending Access-Accept/Access-Reject  …" messages in the debug log.
>> The last message is always something like "Debug: (0) Auth-Type = Accept, accepting the user" but nothing regarding a response follows.
>> We suspected SSL errors but don't find anything suspicious in the logs (server and client).
> 
>  I thought that was fixed... IIRC, the *debug* log didn't show
> anything, but it still sent packets.
> 
>  I'll see if I can figure it out.

That'd be great!
The client didn't seem to "understand" the packets since it complained about timeouts.
No additional (useful) details in the client's logs.
We'll try and use ssldump or a similar tool to get more info.


>> The second problem is that we don't find any hints in the docs on how to configure FR 3.x to listen to both auth and acct using RadSec on port 2083.
>> For instance: When the server receives an Accounting-On packet, we're seeing the following line in the log:
>> Invalid packet code 4 sent from client test port 3065 : IGNORED
>> 
>> We're using the latest git HEAD.
> 
>  Please use v3.0.x.  It's the stable v3 release.  Git "master" branch
> will be massively butchered to fix up historical issues with the API.

We just switched to v3.0.x and are now getting segmentation faults whenever FR tries to use rlm_sql.
We'll take a closer look.


>  The code *used* to allow "auth+acct" for TCP sockets.  I'm not sure
> when that was removed.  I've added it back in, and updated
> raddb/sites-available/tls

Great!! Thanks a lot!

Cheers,
JB