inimizing of unexpected messages, I am definitely with you on this
> one.
>
> -Original Message-
> From: Heikki Vatiainen [mailto:h...@open.com.au]
> Sent: Wednesday, February 19, 2014 9:35 AM
> To: Garry Shtern; 'radiator@open.com.au'
> Subject: Re: [RADIATOR]
om.au'
Subject: Re: [RADIATOR] (P)EAP flow
On 02/17/2014 05:16 PM, Garry Shtern wrote:
> Would it make sense not modify Radiator behavior to only send reject
> if the OpenSSL returns mismatch rather than unexpected record?
Then there would need to be a correct request coming in later
; *Sent: *Monday, February 17, 2014 02:22 PM Coordinated Universal Time
> *To: *radiator@open.com.au
> *Subject: *Re: [RADIATOR] (P)EAP flow
>
> On 02/14/2014 07:17 PM, Garry Shtern wrote:
>> I have noticed that if Radiator receives a midstream EAP exchange
>> message, it r
d.com)
-Original Message-
From: Heikki Vatiainen [h...@open.com.au<mailto:h...@open.com.au>]
Sent: Monday, February 17, 2014 02:22 PM Coordinated Universal Time
To: radiator@open.com.au
Subject: Re: [RADIATOR] (P)EAP flow
On 02/14/2014 07:17 PM, Garry Shtern wrote:
> I have n
On 02/14/2014 07:17 PM, Garry Shtern wrote:
> I have noticed that if Radiator receives a midstream EAP exchange
> message, it responds back with a CHALLENGE.
I would expect something like this with PEAP.
ERR: EAP TLS error: -1, 1, 8465, 13062: 1 - error:140940F5:SSL
routines:SSL3_READ_BYTES:unex
I have noticed that if Radiator receives a midstream EAP exchange message, it
responds back with a CHALLENGE. I am trying to understand what exactly happens
at this point. Does the Supplicant respond to the challenge with a brand new
exchange or just retransmits whatever packet it sent before?
