...

In the above example, a wifi router is providing access to the 192.168.254.0/24 network. When a device (called a supplicant) attempts to connect to the wifi network, the wireless router starts an EAP conversation with the supplicant over 802.1X, requesting it to supply credentials. The router then connects to the authentication server (which, in the example above is also part of the 192.168.254.0/24 network) and sends the EAP response it received from the supplicant over the RADIUS protocol in a packet of type Access-Request as one of the attributes. The authentication server may wish to request the client for more information, it may thus answer the wifi router with a RADIUS packet of type Access-Challenge containing an EAP message to be forwarded to the supplicant. The NAS facilitates this conversation between authentication server and supplicant until the authentication server sends a packet to the NAS which is of either type Access-Accept or Access-Reject. At least some of the communication taking place within the EAP protocol is encrypted (according to the comment in mods-available/eap at line '@@@' the hierarchy is RADIUS → EAP → TLS → Diameter (protocol comparable in scope to RADIUS) → again EAP → the actual protocol used for authentication), in the case an encrypted authentication method is used, the data/attributes contained directly in the RADIUS conversation are unencrypted. The RADIUS conversation part is called the "Outer Tunnel", whereas the (Diameter?) conversation within the TLS encryption is called the "Inner Tunnel", data/attributes sent in this conversation are encrypted.  In At the time of setting up the encrypted tunnel, the authentication server presents a certificate identifying itself which the supplicant may (and should) choose to verify before sending its login credentials to the server. In the case of an Access-Accept, the wifi router now allows the supplicant to join the network, or, in the case of Access-Reject, will not. Once the NAS has granted access, for 802.1X/RADIUS/authentication server, the job is done, and the supplicant becomes part of the 192.168.254.0/24 network's broadcast domain. The authentication server, can specify attributes in replying packet to give the NAS additional instructions, for example, it might request the NAS to place the newly connected supplicant in a specific VLAN, or it might specify for how long the supplicant is allowed to remain connected, or  It can now initiate a DHCP request for an IP address or any other action as may be appropriate. The authentication server is able to log that the user connected along with information from attributes the NAS might have sent, generally this includes the MAC address of the supplicant, MAC address of the NAS, username (if authentication was done by username/password) and more depending on the NAS model.

EAP and RADIUS are both general purpose protocols that take care of communication. They have support for a great variety of features or different methods to perform authentication (e.g. it is possible to use different protocols that authenticate the user using a username and password, or using client certificates, or even SIM cards), but it is still up to the supplicant, NAS and authentication server implementations to choose which ones they support or not (even different NASes have been seen to send MAC addresses in different format, e.g. TP-Link Archer C20 sends 01-23-45-67-89-AB, while TP-Link TD-W8968 sends 0123456789ab). In fact, EAP is only a tunneling protocol inside which a suitable protocol for performing authentication needs to be used. This makes it possible to have flexibility in usable authentication protocols whilst maintaining compatibility with any NAS, as long as the authentication protocol is supported by both the supplicant and authentication server.

Misc. Information

• The RADIUS protocol also includes the possibility for the NAS to send accounting information to the authentication server for the purpose of logging user activity, this is on a separate port, UDP 1813, this has not been investigated as it seems to be not supported by the NASes we have, and presumably is not on any NAS in the price range.

• The RADIUS protocol also includes the possibility for the authentication server to initiate a connection to the NAS and inform it to disconnect a currently logged in user, but again, this has not been investigated much as it seems to be not supported by the NASes we have, and presumably is not on any NAS in the price range.

• In absence of the above mentioned feature, once a user has connected, there is no way to disconnect them other than rebooting the NAS. If the system administrator chooses to disable a user account on the authentication server, the user will be denied access only from the next time they try to connect, if they are already connected at the time of disabling the account, they will remain connected for the moment. It is possible for the authentication server to specify with the "Session-Timeout" and "Termination-Action" attributes of the Access-Accept packet for how long a user is allowed to remain connected without repeating authentication (again subject to NAS supporting). Depending on the NAS and supplicant models it has been observed that there can be a new authentication request, in the case of wifi, when the supplicant moves out of range of the wifi and then comes back, or when the user switches wifi off and on again on the supplicant, but might also not be the case.

Misc. Information:

• A "User-Name" attribute is usually provided in both the outer and inner tunnels, often referred to as outer identity and inner identity, respectively. It is often suggested to send the real username only in the inner tunnel for privacy reasons as it is encrypted, and send the string 'anonymous' as User-Name in the outer tunnel, it was found, however, to be unreasonably difficult, if at all possible, to configure Mac OS, Windows and iPhone clients to do so. The 'User-Name' attribute in the outer tunnel is still necessary as a realm for the user may be specified which might need to be accessed by a RADIUS server which might forward the request and be unable to read the encrypted part. If the user name is anonymized and a realm needs to be specified, the attribute would read 'anonymous@realm'.
• It is possible for a FreeRADIUS server to forward a request to an upstream RADIUS server to handle. The answer then gets sent back and the local FreeRADIUS server forwards it to the client. Usually intermediary RADIUS servers are not able to decrypt the data within the SSL tunnel, and do not have access to it. One way for a RADIUS server to determine whether it should answer a given query itself or forward it upstream is to look at the domain part of the outer identity provided in the outer tunnel.
• According to Wikipedia, there is a similar protocol evolved from RADIUS, called Diameter: https://en.wikipedia.org/wiki/Diameter_(protocol)
• In Debian, the FreeRADIUS daemon is called freeradius. Apparently, in many other environments it is called radiusd.
• When debugging, it is recommended to stop the FreeRADIUS daemon and run freeradius -X in a terminal. A lot of debug information is then printed on the screen, which can be used to see what's happening. This is stressed a lot on the FreeRADIUS wiki and users' mailing list.

Things to mention:

Proxying

features supported by TP-Link NASes

Terminology: NAS, RADIUS, FreeRADIUS, Authenticator, Supplicant, Authentication server

Diameter

Protocols used: EAP, MSCHAP, PEAP, TTLS, TLS

...

Wifi keying, session timeout, etc. protections against MAC-spoofing, etc.

SSL tunnel

freeradius -X. radiusd vs freeradius

Terminology: NAS, RADIUS, FreeRADIUS, Authenticator, Supplicant, Authentication server - Done

Diameter - Done

Outer and inner identity and MAC/Windows support - Done

...

Re-auth, accounting, request from server, - Done

freeradius -X. radiusd vs freeradius - Done

FreeRADIUS configuration files

...

http://lists.freeradius.org/mailman/listinfo/freeradius-users

It is stressed in the FreeRADIUS wiki to only follow documentation from the official wiki, as third party documentation is often outdated and/or incorrect.