After the marshmellow incident, I thought it might be a good idea to properly integrate eapol_test into Travis CIT. Travis now builds eapol_test on each CIT run (only takes ~10s), and uses it to execute test files in src/tests/eapol_test. We'll see how stable this arrangement is, we may need to switch to stable releases of the hostapd repo if CIT keeps failing. The idea is that we detect interop issues as early as possible, and ensure the version of eapol_test is compatible with the OpenSSL ABI for the version installed by Travis (we wouldn't get that if eapol_test were compiled and bundled with the server source). I've expanded the eapol_test, test suite, to include: * eap-gtc * eap-leap * eap-ttls-chap * eap-ttls-client-eap-tls (tls in eap in diameter in tls in eap in radius, with certs) * eap-ttls-client-eap-mschapv2 * peap-eap-gtc. The complete list is: * eap-gtc * eap-leap * eap-md5 * eap-pwd * eap-mschapv2 * eap-tls * eap-ttls-chap * eap-ttls-client-eap-mschapv2 * eap-ttls-client-eap-tls * eap-ttls-eap-mschapv2 * eap-ttls-mschapv2 * eap-ttls-pap * peap-client-mschapv2 * peap-eap-gtc * peap-mschapv2 Any other bizarre EAP types in use that i've missed? Planning to add eap-sim as well, once the compilation errors in wpa_supplicant/eapol_test builds with EAP sim support (get compilation errors currently). Also discovered the reason why we support including the length flag in each TLS record fragment. Apparently PEAPv0 with mutual auth sends all the client certificate fragments with the L flag set. Or at least that's what the wpa_supplicant implementation does, and i'm assuming that was based off of the observed behaviour of the Windows supplicant. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2