EAP-TLS not successful
Tue Jun 16 20:58:44 PDT 2015
Thanks Jouni. Appreciate your response
Let me check again with the client output.
On Sun, Jun 14, 2015 at 1:51 AM, Jouni Malinen <j at w1.fi> wrote:
> On Thu, Jun 11, 2015 at 02:50:58PM -0700, Premraj Sundaram wrote:
> > I was using JRadiusSimulator GUI as the client.
> > The same client works with FreeRadius and returns Access-Accept.
> That's strange if the test was done with same EAP-TLS fragmentation
> behavior from the client.. If that worked, the server would need to
> ignore incorrect TLS Message Length value (which, I'd assume, is
> possible for FreeRADIUS to do, e.g., as an interoperability workaround;
> I did not check its current implementation for this).
> > I would prefer to make hostapd work, because my next step is to do
> > EAP: EAP entering state INTEGRITY_CHECK
> > EAP: EAP entering state METHOD_RESPONSE
> > SSL: Received packet(len=456) - Flags 0x00
> > SSL: Received packet: Flags 0x0 Message Length 0
> > SSL: Fragment overflow
> > EAP-TLS: CONTINUE -> FAILURE
> > The above lines make me thinking whether it could be an SSL issue.
> It is not; this is fragmentation issue in EAP-TLS, i.e., something that
> happens before SSL (or well, TLS) processing. The test client is
> claiming that the TLS Message Length is 1028 octets of which the first
> 1024 octets are included in the first message (the first fragment). That
> would mean that the second fragment would need to include the remaining
> 4 octets. However, the second message includes about 434 octets which
> hostapd is rejecting as invalid ("SSL: Fragment overflow") which is the
> expected behavior with such a clearly incorrect fragmentation of an
> EAP-TLS message.
> Jouni Malinen PGP id EFC895FA
> HostAP mailing list
> HostAP at lists.shmoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap