RE: EAP-TLS context uninitialized
Hi Arran, I'll check the NAS but am confused as it should (to me) have been a problem before. Pre-auth is turned on, but never caused a problem previously. It seems to be generally worse when there are lots of auth requests, but then sometimes there's just one happening and it'll do it. It's not related to client detail, as sometimes a specific client is fine, and on another occasion it'll fail. I've yet to check it in non-debug mode, which is a bit daft of me, it's obviously running single threaded and echoing to screen, maybe that's slowing it to "not coping" point. I'll keep digging, guess there's nothing obvious between versions? Thanks! Andy ________________________________________ From: Freeradius-Users [freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradius.org] on behalf of Arran Cudbard-Bell [a.cudbardb@freeradius.org] Sent: 05 January 2016 18:06 To: FreeRadius users mailing list Subject: Re: EAP-TLS context uninitialized
On Jan 5, 2016, at 12:53 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks@sath.nhs.uk> wrote:
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:
Do you have session resumption enabled? Could be an issue with that. -Arran
On Jan 5, 2016, at 2:28 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks@sath.nhs.uk> wrote:
Hi Arran, I'll check the NAS but am confused as it should (to me) have been a problem before. Pre-auth is turned on, but never caused a problem previously.
That's different, you're talking about 802.11 PMK caching, this is TLS session resumption where the keys, certificates, and negotiated cipher suites from a previous TLS session are re-used. TLS session resumption controlled by the cache section in the eap configuration file. Should be a toggle. If it's not there try using an updated version of the mods-available/eap file, many settings for cache control have changed.
It seems to be generally worse when there are lots of auth requests, but then sometimes there's just one happening and it'll do it. It's not related to client detail, as sometimes a specific client is fine, and on another occasion it'll fail. I've yet to check it in non-debug mode, which is a bit daft of me, it's obviously running single threaded and echoing to screen, maybe that's slowing it to "not coping" point.
Not unless you're putting significant load on it.
I'll keep digging, guess there's nothing obvious between versions?
No, and i've never seen that message before, but we have rewritten a lot of the EAP-TLS code in v3.1.x. Knowing OpenSSL version would be useful too (output at the top of the radiusd -X output), I mostly test with 1.0.2 Travis will probably be 0.9.8 so interactions with 1.0.0 and 1.0.1 are not well tested. -Arran
participants (2)
-
Arran Cudbard-Bell -
Franks Andy (IT Technical Architecture Manager)