EAP-TLS context uninitialized
Franks Andy (IT Technical Architecture Manager)
Andy.Franks at sath.nhs.uk
Tue Jan 5 18:53:32 CET 2016
Hi all,
I've a problem with FR3.1.0 git#f4d5ff6. This is on our test "wireless" radius server, and I'm looking to commission the configuration onto more production systems once it's certified. Basically the only changes are a newer version of FR, and some tidying of the config. The older version is git #390f216. When sending the same clients to both, very often the newer one complains with this issue and rejects the user:
(85) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(85) Auth-Type eap {
(85) eap: Peer sent packet with method EAP TLS (13)
(85) eap: Calling submodule eap_tls to process data
(85) eap_tls: Continuing EAP-TLS
(85) eap_tls: Peer indicated complete TLS record size will be 131 bytes
(85) eap_tls: Got complete TLS record, with length (131 bytes)
(85) eap_tls: [eap-tls verify] = ok
(85) eap_tls: before/accept initialization
(85) eap_tls: TLS Accept: before/accept initialization
(85) eap_tls: <<< recv handshake [length 126], client_hello
tls: TLS Accept: Error in SSLv3 read client hello C
tls: TLS Accept: Error in SSLv3 read client hello C
(85) eap_tls: ERROR: TLS says: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized
(85) eap_tls: ERROR: TLS_read failed in a system call (-1), TLS session failed
(85) eap_tls: ERROR: TLS receive handshake failed during operation
(85) eap_tls: ERROR: [eap-tls process] = fail
(85) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed
(85) eap: Sending EAP Failure (code 4) ID 45 length 4
(85) eap: Failed in EAP select
The confusing thing is it's not consistent - sometimes it will be ok, I've not yet worked out the pattern:
(75) Auth-Type eap {
(75) eap: Peer sent packet with method EAP TLS (13)
(75) eap: Calling submodule eap_tls to process data
(75) eap_tls: Continuing EAP-TLS
(75) eap_tls: Peer indicated complete TLS record size will be 133 bytes
(75) eap_tls: Got complete TLS record, with length (133 bytes)
(75) eap_tls: [eap-tls verify] = ok
(75) eap_tls: before/accept initialization
(75) eap_tls: TLS Accept: before/accept initialization
(75) eap_tls: <<< recv handshake [length 128], client_hello
(75) eap_tls: TLS Accept: SSLv3 read client hello A
(75) eap_tls: >>> send handshake [length 89], server_hello
(75) eap_tls: TLS Accept: SSLv3 write server hello A
(75) eap_tls: >>> send handshake [length 2344], certificate
(75) eap_tls: TLS Accept: SSLv3 write certificate A
(75) eap_tls: >>> send handshake [length 331], server_key_exchange
(75) eap_tls: TLS Accept: SSLv3 write key exchange A
(75) eap_tls: >>> send handshake [length 104], certificate_request
(75) eap_tls: TLS Accept: SSLv3 write certificate request A
(75) eap_tls: TLS Accept: SSLv3 flush data
(75) eap_tls: TLS Accept: Need to read more data: SSLv3 read client certificate A
(75) eap_tls: TLS Accept: Need to read more data: SSLv3 read client certificate A
(75) eap_tls: In TLS handshake phase
(75) eap_tls: In TLS accept mode
(75) eap_tls: [eap-tls process] = handled
(75) eap: Sending EAP Request (code 1) ID 71 length 1090
(75) [eap] = handled
(75) } # Auth-Type eap = handled
It doesn't happen on the older version (at all) and that has very similar config. Is there any known reason why this should be coming up? The NAS and clients are identical during each test, the older version is fine, the newer not. The host machines were built at the same time, so the dev libraries compiled against are likely the same versions.
I'm stumped! Is it worth me moving to a newer build and trying again - any known issues?
Thanks!
Andy
More information about the Freeradius-Users
mailing list