I have an end-to-end setup working (more or less) with a TL-SG3424 and Ubuntu clients using EAP-MD5 and a Windows Server 2012R2 NPS server (RADIUS).
Yet it's not really 100% working. Problem is that between 20-30secs after successfully authenticating the client and connecting it to the right VLAN, the switch logs a "Authentication exit" message in the logs and the port is going back to the guest VLAN.
After analyzing network traces using the TP-Link 802.1x client on a Windows machine I found that the client is sending the switch some kind of "heartbeat" masquerade as a EAPPOL-MAK package. I use the word masquerade because the packet doesn't look like a valid EAPPOL-MAK packet but a customized one.

I already opened a support ticket with TP-Link since it's really annoying that 802.1x requires a closed source/customized client that only runs on Windows.
Once I hear from them I will post the findings here.

I have some news about this.
After opening a support case with TP-Link the outcome is that they only support 802.1x for Windows clients running the TP-Link 802.1x client software.
This is very disappointing since 802.1x is an standard and I can't understand why they can't adhere to the standard and support other 802.1x clients running on Linux or Mac.

Bottom line, if you are working in a mixed environment that is not only running Windows clients and you want to implement 802.1x in your network, then stay away from TP-Link switches.

It's a shame, they just lost a loyal customer. :(

We have the same issue on the T1600 series, and it's TP-Link Bug. You can work around it with the following settings:

Authentication Config:
* Quiet: Enable
* Quiet Period: 1
* Retry Times: 9
* Supplicant Timeout: 9

It reduces the chance that Authorization fails to 1/81.

Ok, so here's the Bug: The router isn't actually quiet, but sill sends authorization requests. Yet it ignores the answers during quiet time.
The default values are: Quiet Period:10; Retry Times: 3; Supplicant Timeout: 3. Thus after 9 seconds (Retry * Timeout) the switch sends a failure and blocks all answers for 10 seconds. 9 Seconds later the next failure is triggered and answers are ignored for another 10 seconds. Thus the supplicant has -1 seconds to answer the request.

So why does the official client work? Windows, MacOS and probably Linux send a EAPOL/Start right away and then show the login-field. If you fill that within 9 seconds you're fine. If not, you're locked out. The TP-Link client however sends EAPOL/Start only after user credentials have been entered and can therefore also answer the first authorization request.

Shouldn't Quiet: Diesable work? Probably should - but doesn't. - At least not for us.