No SSL info available. Waiting for more SSL data with Red Hat 7.1
Hi all, At home I've configured a perfectly working freeradius with PEAP/MSCHAPv2, I'd like to transfer it to my work to some really old red hat 7.1 boxes. First I configured and freeradius from source and installed in prefix /usr/local but it crashed on the old ssl, so I grabbed the latest openssl configured it and installed in /usr/local as well, recompiled freeradius with the appropiate ssl directories and it ran! I transferred the configuration from my server at home and converted the appropiate paths. I tried authenticating on but it failed, the only suspicious thing I could find is: rlm_eap_tls: No SSL info available. Waiting for more SSL data. After three of these attempts the supplicant (winxp sp2) seems to bail out, xsupplicant seems to give it some more tries. What am I missing? TIA Dick
Dick <dm@chello.nl> wrote:
I suppose freeradius 1.0.4 is incompatible with glibc 2.2,
No.
Could somebody please confirm this?
The "NO SSL Info available" message means that the supplicant isn't sending the data it's supposed to send. Fix the supplicant. Alan DeKok.
Hi Alan de Kok, Alan DeKok <aland <at> ox.org> writes:
Dick <dm <at> chello.nl> wrote:
I suppose freeradius 1.0.4 is incompatible with glibc 2.2, No. Could somebody please confirm this? The "NO SSL Info available" message means that the supplicant isn't sending the data it's supposed to send.
Fix the supplicant.
Thanks for your reply, But the same supplicant *is* working using freeradius compiled with glibc-2.3. It might be something else but I don't know what, suggestions? greetings, Dick
Dick <dm@chello.nl> wrote:
But the same supplicant *is* working using freeradius compiled with glibc-2.3.
That's very, very, weird.
It might be something else but I don't know what, suggestions?
I would suggest going through the debug logs for the two different servers, and comparing the packets in detail. Find out what the differences are, and why. That will tell you what's going on. Are you *sure* that the only differences in the two installations is glibc? Maybe there's incompatible OpenSSL versions? Alan DeKok.
Alan DeKok <aland <at> ox.org> writes:
I would suggest going through the debug logs for the two different servers, and comparing the packets in detail. Find out what the differences are, and why. That will tell you what's going on.
the problems start with the following difference: from glibc-2.2 radius: rlm_eap_tls: Length Included eaptls_verify returned 11 TLS_accept: SSLv3 read client key exchange A TLS_accept: SSLv3 read finished A TLS_accept: SSLv3 write change cipher spec A TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully from glibc-2.3 radius: rlm_eap_tls: Length Included eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully
Are you *sure* that the only differences in the two installations is glibc? Maybe there's incompatible OpenSSL versions?
The captured packets are completely different, the glibc-2.2 capture contains a NAS identifier, NAS Port, Framed MTU, NAS Port Type in the Access Request but the glibc-2.3 capture seems to lack this information. While the request came from the same accesspoint! (with an other radius server configured) Does this ring a bell? Thanks so far, greetings Dick
Dick <dm <at> chello.nl> writes:
Are you *sure* that the only differences in the two installations is glibc? Maybe there's incompatible OpenSSL versions?
I don't think so, I'm using a self compiled prefixed (/usr/local) openssl-0.9.7g. Although the /lib/libcrypt.so.1 and /usr/lib/libssl.so.1 are still used by /usr/local/sbin/radiusd (according to ldd)
Dick <dm@chello.nl> wrote:
I don't think so, I'm using a self compiled prefixed (/usr/local) openssl-0.9.7g. Although the /lib/libcrypt.so.1 and /usr/lib/libssl.so.1 are still used by /usr/local/sbin/radiusd (according to ldd)
I'll bet that's the problem. Having two versions of OpenSSL on the same system is a bad idea. Alan DeKok.
Alan DeKok <aland <at> ox.org> writes:
Dick <dm <at> chello.nl> wrote:
I don't think so, I'm using a self compiled prefixed (/usr/local) openssl-0.9.7g. Although the /lib/libcrypt.so.1 and /usr/lib/libssl.so.1 are still used by /usr/local/sbin/radiusd (according to ldd)
I'll bet that's the problem.
Having two versions of OpenSSL on the same system is a bad idea.
/lib/libcrypt.so.1 and /usr/lib/libssl.so.1 seem to be part of glibc I won't upgrade the openssl installation, I'd better upgrade the whole system ;) Thanks
participants (2)
-
Alan DeKok -
Dick