rlm_eap_tls: No SSL info available. Waiting for more SSL data
I have setup freeradius-1.1.4 for 802.1x authentication and tested it successfully using eapol_test. When I try to authenticate a voip phone, that uses the same certificate as I used before with eapol_test, authentication fails. radiusd -AX shows: ... rad_check_password: Found Auth-Type EAP^M auth: type "EAP"^M Processing the authenticate section of radiusd.conf^M modcall: entering group authenticate for request 1^M rlm_eap: Request found, released from the list^M rlm_eap: EAP/tls^M rlm_eap: processing type tls^M rlm_eap_tls: Authenticate^M rlm_eap_tls: processing TLS^M rlm_eap_tls: Received EAP-TLS ACK message^M rlm_eap_tls: No SSL info available. Waiting for more SSL data.^M eaptls_verify returned 1 ^M eaptls_process returned 13 ^M ... 'Waiting for more SSL data' seems to be the interesting point. freeradius is obviously waiting for some data from the client. Is there anything I can configure on the server side or is this a problem with the switch/ the voip phone? The logfile is at http://www.wegener-net.de/fr/typescript.txt Norbert Wegener
Norbert Wegener wrote:
I have setup freeradius-1.1.4 for 802.1x authentication and tested it successfully using eapol_test. When I try to authenticate a voip phone, that uses the same certificate as I used before with eapol_test, authentication fails.
Different implementations, different issues...
'Waiting for more SSL data' seems to be the interesting point. freeradius is obviously waiting for some data from the client.
And the client is probably waiting for more data from FreeRADIUS.
Is there anything I can configure on the server side or is this a problem with the switch/ the voip phone?
I would label it a bug with the client. But I'm biases. My worry is that "fixing" it on the server could mean breaking 802.1x for other clients. That's a non-starter. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Norbert Wegener wrote:
I have setup freeradius-1.1.4 for 802.1x authentication and tested it successfully using eapol_test. When I try to authenticate a voip phone, that uses the same certificate as I used before with eapol_test, authentication fails.
Different implementations, different issues...
'Waiting for more SSL data' seems to be the interesting point. freeradius is obviously waiting for some data from the client.
And the client is probably waiting for more data from FreeRADIUS.
Is there anything I can configure on the server side or is this a problem with the switch/ the voip phone?
I would label it a bug with the client. But I'm biases.
Is there anything I can do on the freeradius side to prove, that the voip phone's 802.1x implementation is broken? Up to now I could not convince the vendor's salesperson, that there is a problem with his phone. Norbert Wegener
My worry is that "fixing" it on the server could mean breaking 802.1x for other clients. That's a non-starter.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Norbert Wegener wrote:
Is there anything I can do on the freeradius side to prove, that the voip phone's 802.1x implementation is broken?
Well, FreeRADIUS works with every *other* 802.1x client out there, including Vista. This means MAC OSX, all versions of Windows, Linux, FreeBSD, NetBSD, Solaris, etc.
Up to now I could not convince the vendor's salesperson, that there is a problem with his phone.
Point him at the survey page on the FreeRADIUS web site. Ask him if he's going to intentionally sell a product that doesn't work with the #1 RADIUS server on the planet. Ask him why his phone won't work with 1/3 or more of the installed RADIUS server market. Ask him why he doesn't want his phone to work with for major telecom companies. Ask him why there are customers with 10-million users that he's ignoring. The problem is likely that the server *could* send more data at a certain point, and instead just sends an "ack". If the client just sends an "ack" back (like everyone else does), then the server sends more data. His phone, on the other hand, expects to see data. Rather than sending an "ack", which means "please give me more data", it just dies. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (2)
-
Alan DeKok -
Norbert Wegener