Jouni Malinen j at
Thu Nov 22 17:06:27 CET 2007

On Thu, Nov 22, 2007 at 01:57:01PM +0100, Alan DeKok wrote:

>   I've just committed some more fixes that make TTLS/PEAP call the
> tls_hanshake_recv() function, which takes care of fragments and ACKs.
> That appears to work a little better.

It looks like I can now receive the first fragment of the long phase 2
message from the server. This is sent in two phase 1 fragments and the
combined data can be decrypted correctly. However, after this, the
server does not seem to be sending out the following data from phase 2.

The phase 2 message (the one with EAP-TLS ServerHello, Certificate,
ServerKeyExchange, and CertificateRequest) is 3808 bytes and it looks
like only the first 1020 bytes (fragment_size - 4 octets for TLS Message
Length field) is transmitted. Is the phase 2 data actually truncated

>   I've made some more hacks (uncommitted) to work around certain
> assumptions in the internal implementation of the server.  I now see the
> connection established, and then the inner EAP-TLS session says:
>   rlm_eap_tls: >>> TLS 1.0 Handshake [length 00a8], CertificateRequest
>     TLS_accept: SSLv3 write certificate request A
>     TLS_accept: SSLv3 flush data
>     TLS_accept: Need to read more data: SSLv3 read client certificate A

This should show up even before the server has sent out the first large
message from phase 2 (I see the same in the debug log).

>   wpa_supplicant sends the certificate in 3 fragments, including change
> cipher specs, and FreeRADIUS receives the fragments. However, FreeRADIUS
> doesn't process the data, and instead asks for more.

However, this would require the larger server message to go through
which is something I do not see. Could you please send me the hacks
needed to get here?

Jouni Malinen                                            PGP id EFC895FA

More information about the Freeradius-Devel mailing list