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. What does the EAP data look like in the packet sent before it breaks immediately after this patch, and in the equivalent packet before this patch? Specifically in EAP-Message it's the 8th bit ("length included") and 7th bit ("more fragments") of the 6th octet ("flags"), the "message length" field (7th, 8th, 9th and 10th octets) and the EAP-Message length (3rd and 4th octets). So fragments should be c0 on the first fragment, 40 on intermediate fragments and 00 on the last fragment. Or 80 for a standalone packet (no further fragments). These look OK in the original debug output, but the lengths for each packet look a bit odd in this sequence starting (1) eap_peap - Complete TLS record (2245 bytes) larger than MTU (1000 bytes), will fragment (1) eap_peap - Sending first TLS record fragment (1000 bytes), 1245 bytes remaining (1) eap_peap - [eap-tls process] = handled (1) vpieap - Sending EAP Request (code 1) ID 4 length 1010 (1) vpieap (handled) (1) } # authenticate (handled) (1) Using Post-Auth-Type Challenge (1) Post-Auth-Type sub-section not found. Ignoring. (1) Running Post-Auth-Type Challenge from file /etc/raddb/sites-enabled/vpi (1) Sent Access-Challenge Id 157 from 137.222.8.134:16020 to 172.17.107.208:32770 via ens192 length 0 (1) EAP-Message = 0x010403f219c0000008c5160301003902000035030156e823361b5cba1ccb77c8d1c2d294e5648fa5293f6acb6c7e0b210e9899de6e00c01400000dff01000100000b00040300010216030107290b0007250007220002dc308202d830820282020410456227300d06092a864886f70d01010b05003081bf (1) Message-Authenticator = 0x00000000000000000000000000000000 (1) State = 0x02036e003ffa67036d696f996ec2a586 (1) Finished request 1000 bytes, 1245 remaining. OK. 000008c5 is 2245. 03f2 is 1010, which is 1000 plus 10 (header octets) but length of that attribute is only 119 octets. Flags are OK. The next two challenges are similar (2) eap_peap - Sending additional TLS record fragment (1004 bytes), 241 bytes remaining (2) eap_peap - [eap-tls process] = handled (2) vpieap - Sending EAP Request (code 1) ID 5 length 1010 (2) vpieap (handled) (2) } # authenticate (handled) (2) Using Post-Auth-Type Challenge (2) Post-Auth-Type sub-section not found. Ignoring. (2) Running Post-Auth-Type Challenge from file /etc/raddb/sites-enabled/vpi (2) Sent Access-Challenge Id 158 from 137.222.8.134:16020 to 172.17.107.208:32770 via ens192 length 0 (2) EAP-Message = 0x010503f219402053657276696365733129302706035504031320556e6976657273697479206f662042726973746f6c2057696e646f7773204341301e170d3033303131303130323733375a170d3233303131303130333531315a3081bf3125302306092a864886f70d010901161663612d61646d696e40 Same length attribute. (3) eap_peap - Sending final TLS record fragment (241 bytes) (3) eap_peap - [eap-tls process] = handled (3) vpieap - Sending EAP Request (code 1) ID 6 length 247 (3) vpieap (handled) (3) } # authenticate (handled) (3) Using Post-Auth-Type Challenge (3) Post-Auth-Type sub-section not found. Ignoring. (3) Running Post-Auth-Type Challenge from file /etc/raddb/sites-enabled/vpi (3) Sent Access-Challenge Id 159 from 137.222.8.134:16020 to 172.17.107.208:32770 via ens192 length 0 (3) EAP-Message = 0x010600f71900ebe0344cb4e5d4ac912e10789408d80c66f81fd27cddd89c4c4a4dc3ae440f0cc86f59ca46e8ff75376eb7910a0af3153626fe0cf81027c02f568b1e56e2656a4191c98103f0da0f1ff061a21c81756cc2aec65066916bda86078229a217c291a4cb982853454ddb46b5e54200d5fd06d4 Same length attribute. It looks to me like the lengths are being set correctly in the attribute, but the actual amount of data sent is just the length of the final fragment (00f7 = 247 bytes). Comparing to debug output from the previous commit would verify this. But can't see how this exact behaviour would be caused by this patch, so maybe I'm completely wrong. I've not had much coffee yet today. 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>