On Tue, Dec 13, 2016 at 12:09:40PM -0500, Thomas d'Otreppe wrote: > I used the default config and an ath9k_htc device (TP-Link TL-WN722N > to be precise) if that matters. > > I copied the log on pastebin: http://pastebin.com/jwtn1TWN So the failure happens when the server needs to fragment a long TLS message (the one that includes the certificate chain from the server). For some reason, the Windows 10 supplicant seems to send out an extra fragment ACK (an empty EAP-PEAP message) after the full fragmented frame has been sent out. In my earlier test, I used a shorter certificate and there was no fragmentation, but I now confirmed that even the fragmented case works fine for me with Windows 10 as the client. Did you use a completely new network profile on Windows 10, i.e., something that has not connected to any other authentication server before? I'm not sure what type of validation steps are performed at this step, but if the client has means for verifying that the server certificate is trusted or known, it could stop authentication here. In any case, it sounds like someone would need to get debug output from Windows 10 to figure out why it either rejects the message from the server (though, uses a bit strange message for doing so, i.e., an empty message instead of TLS alert or disconnection) or why it thinks there is still some fragments coming up. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
