On Fri, Mar 18, 2016 at 12:02:40PM +0000, Matthew Newton wrote:
On Fri, Mar 18, 2016 at 09:23:20AM +0000, Scott Armitage wrote:
Alan Buxey and myself have spent some time and believe we have tracked down the commit which broke EAP:
commit 8a7f6e330f45439d333f61dde7ee0982ebcc2a29 Author: Arran Cudbard-Bell <a.cudbardb@freeradius.org> Date: Sun Dec 6 00:34:21 2015 -0500
Add additional debugging so we can track TLS fragments sent
Hmm. If that's the case, then the bug is probably to do with the length included flag and the length of the packet.
Close. Think I may have found it. Have found the differences, anyway. First confusing thing is the FreeRADIUS is only printing out the first EAP-Message attribute in the debug output, hence the lengths before looked wrong (e.g. showing length 1000, but only having 247 or so bytes in the response). This is just because the other three EAP-Message attributes aren't being printed. Testing here with eapol_test shows that they are being returned correctly and this is only a debug output issue. The new code, for fragmented packets, is arguably more correct. In 8a7f6e330f^, in my test here, I have Challenge 1: length 1004, flags L+M Challenge 2: length 1000, flags M Challenge 3: length 726 Total length 2730, all verified OK (correct lengths in packets etc) as far as I can tell. In 8a7f6e330f (with the patch) for the same request/config I get: Challenge 1: length 1000, flags L+M Challenge 2: length 1000, flags M Challenge 3: length 730 So it's not going over the MTU, which is better. However... The key difference seems to be that in packets that do *not* need fragmenting, the L flag and length are now included, whereas in 8a7f6e330f^ they are not. This seems fine in the PEAP negotiation stage, but fails on the first packet after PEAP goes into its inner tunnel. My hypothesis would be a supplicant bug that sees the Length flag set so erroneously expects more packets, but that should not be the case because M was not set. It certainly works fine in eapol_test both pre- and post-8a7f6e330f, so it seems down to the way the particular supplicant processes the reply. draft-josefsson-pppext-eap-tls-eap-02 is silent on this matter it seems. L and M MUST be set for the start of fragments, L to set the length of the whole amount of data. But there is no mention of whether L on its own (for a non-fragmented packet), without M, is banned. Certainly the supplicant seems to send data this way to the server, and other packets are sent like this back to the supplicant, hence guessing this change in behaviour is just hitting one particular Windows supplicant in the wrong places. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>