Alan DeKok wrote:
JB wrote:
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.
OK.
This is the output of ssldump monitoring the port 2083: 1 1 0.0194 (0.0194) C>S Handshake ClientHello […] 1 2 0.0514 (0.0319) S>C Handshake ServerHello […] 1 9 1.2804 (0.0000) C>S Handshake 1 10 1.2993 (0.0188) S>CShort record Unknown SSL content type 1 1 11 1.3307 (0.0314) C>S application_data 1 12 1.3767 (0.0459) S>CShort record 1 13 10.0033 (8.6265) C>S application_data 1 14 20.0124 (10.0090) C>S application_data 1 15 30.0219 (10.0095) C>S application_data 1 16 40.0317 (10.0097) C>S application_data 1 17 563.3482 (523.3165) C>S application_data 1 563.3491 (0.0009) C>S TCP FIN 1 563.3517 (0.0025) S>C TCP FIN You can see the Access-Request retries after 10 seconds respectively. Shouldn't there be "S>C application_data" entries? Can it be that FR really doesn't send anything back or am I interpreting this the wrong way? Anyway, we ruled out the firewall by shutting it down completely. We tested with a fresh build using only the "default" and "tls" sites. We just added our certificates and clients. Logins without RadSec work fine using the same clients. Radsecproxy also works fine using the same clients and certificates.
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.
Please double-check that you're using the v3.0.x libraries with the v3.0.x server. If the v3.0.x server is using the libraries from the "master" branch, it won't work.
It seems that our repository was indeed mixed up. We cleaned up and cloned the branch v3.0.x again and the segfaults stopped. (Instead, we saw a talloc error followed by an abort once but failed to save the logs. We will post as soon as this happens again.) Cheers! JB