Yes, I used a completely new profile. I listed all network available, selected my attacker's network and put credentials (login: me, password: password). Could you tell me where I can find that debug output? Is there anything I need to filter on? Would a pcap from a separate machine help? Thomas On Tue, Dec 13, 2016 at 1:35 PM, Jouni Malinen <j@xxxxx> wrote: > 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
