Welcome to TP-LINK Tech Support Forum
+ Reply to Thread
Results 1 to 4 of 4
  1. #1

    802.1X wired setup for Linux

    Region : Germany

    Model : TL-SG3216

    Hardware Version : V1

    Firmware Version : 2.1.6 Build 20141218 Rel.61735(n)

    ISP : Telekom


    Hi,

    I have 802.1X AAA woking with a freeradius server, some TP841 Wifi routers and mobile devices based on Android and Win7. I also managed to get wired 802.1X working on win7 using the 2013 version of the TP-Link Supplicant software. But I fail to get wired connection working for my raspberry pi Linux devices (raspian /debian wheezy. Wifi connection using certificates work). So far I don't even come to the point where the switch communicates with the radius server (freeradius -X does not show any output), things seem to fail while the supplicant is still negotiating with the switch. As I am not really skilled in this, does anyone have an end-to-end setup example for a Debian/TL-SG..../freeradius setup?

  2. #2
    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.

  3. #3

    Unhappy

    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.

  4. #4

    Unhappy

    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.


 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Copyright 1996-2017 TP-LINK Technologies Co., Ltd. All rights reserved.