...

In the above example, a wifi access point 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 access point starts an EAP conversation with the supplicant over 802.1X, requesting it to supply credentials. The router access point 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 supplicant for more information, it may thus answer the wifi router access point with a RADIUS packet of type Access-Challenge containing an EAP message to be forwarded to the supplicant. The NAS wifi access point facilitates this conversation between authentication server and supplicant until the authentication server sends a RADIUS packet to the NAS wifi access point which is of either type Access-Accept or Access-Reject.

EAP itself is an encapsulation protocol, inside it a variety of different protocols can be run to perform authentication. An authentication protocol can be encapsulated directly inside the EAP tunnel or an encryption protocol can be, inside which then, (at least in the cases of EAP-PEAP and EAP-TTLS) eventually another instance of the EAP protocol is encapsulated, inside which, finally, the actual authentication protocol is encapsulated. According to the comment in the mods-available/eap config file at the beginning of the 'ttls' section, the hierarchy with EAP-TTLS is RADIUS → EAP → TLS → Diameter (protocol comparable in scope to RADIUS) → again EAP → the actual protocol used for authentication). EAP-PEAP is a comparable encryption protocol , it is possible to use either that can be used instead of EAP-TTLS or EAP-PEAP. An example of an authentication protocol that can be used for the actual authentication is MSCHAPv2.

In the case an encrypted tunnel is used, the conversation outside the encryption encrypted tunnel is called the outer tunnel. The conversation within the encrypted tunnel is called the "Inner Tunnel". 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 NAS wifi access point 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 the 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. 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. The supplicant can now initiate a DHCP request for an IP address or any other action as may be appropriate.

...

FreeRADIUS configuration files are many. They are located in /etc/freeradius/3.0 on Debian systems. Other distributions  Apparently, many other environments use a slightly different location. Most of them contain plenty of comments explaining what the configuration does and advice and warnings, but some understanding of the protocols, or getting used to, is often necessary to understand them. Here are The FreeRADIUS technical guide (link in "Support / Knowledge places" section) describes them in more detail along with more useful information. Here is a brief look at some of the configuration files/folders:

clients.conf - List of clients that will be connecting to the FreeRADIUS server, including their IP addresses and passwords that they will use to authenticate to FreeRADIUS. What is called a FreeRADIUS client is actually a NAS, not a supplicant. Supplicants do not speak directly to RADIUS servers.

...

1. 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.

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

3. 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.
4. 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 . 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 useful as a realm for the user may be specified and a RADIUS server might need to forward the request to another RADIUS server, based on the specified realm and might be unable to read the encrypted inner-tunnel. If the outer user name is anonymized and a realm needs to be specified, the attribute would read 'anonymous@realm'.
5. 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. It is possible (or maybe most of the time/always the case?) that intermediary RADIUS servers are not able to decrypt the data within the encrypted inner-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 realm part of the outer identity provided in the outer tunnel.
6. According to Wikipedia, there is a similar protocol evolved from RADIUS, called Diameter: https://en.wikipedia.org/wiki/Diameter_(protocol)
7. In Debian, the FreeRADIUS daemon is called freeradius. Apparently, in many other environments it is called radiusd.
8. 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.
9. A system called RSN pre-authentication (sometimes called WPA2 pre-authentication) can be used, when multiple NASes are installed in a network, which allows the NASes to talk amongst themselves and inform other NASes about supplicants that have authenticated through them. This allows a wireless supplicant that moves within the building to connect to a different NAS without having to repeat RADIUS authentication. This feature has not been investigated much. It might be that it is only available on wireless LAN NASes. It is suspected that this feature is the cause of the Session-Timeout / Termination-Action attributes not working in some corner cases (observed sometimes when the supplicant roamed between different NASes in a particular order), resulting in the supplicant remaining connected to the network longer than the specified limit, without repeating authentication to the RADIUS server.
10. Through a rather limited amount of research in this regards, it is my understanding that for each supplicant a different key is generated and used to encrypt wireless traffic between communication between it and the NAS once authenticated, and is generated in part using also a key provided by the RADIUS server, and supplicant and NAS MAC addresses. A supplicant, during authentication specifies its MAC address as well as login credentials, which is logged in the RADIUS server along with user details. After authentication, the NAS does not As per tests, it is inferred that, after a supplicant connects to the wifi network, the NAS does not allow the supplicant to send packets with a source MAC address other than the one specified during authentication. '@@@' (to be verified) This protects against MAC spoofing once a user is logged into the network.There are two different WPA standards, WPA and WPA2. when connecting. This was tested on a TP-Link TL WR740N, with 802.1X wireless security as well as with wireless security disabled, and on a TP-Link Archer C20 with wireless security disabled using 'ostinato' (package available in Debian repositories) to transmit test packets. This protects against MAC spoofing once a user is logged into the network. 
11. There are two different WPA standards, WPA and WPA2. The latter is the proper one, and the former was released as an interim solution to be applied on existing devices with inadequate hardware for running WPA2 due to the urgency of upgrading from WEP which was at the time discovered to be significantly insecure. Similarly there is an "encryption" setting in most NASes with two possible settings, TKIP and AES, where AES is the proper solution, and TKIP the interim one.
12. Please see the "Supplicant configuration" and "WiFi access point (NAS) configuration" section sections of the "802.1X secured wifi installation" page's "Installation" child page for more information about features supported by and behavior specific to some NAS models and supplicants.
13. EAP-TLS is an authentication method protocol that can be used to authenticate supplicants based on client certificates.on client certificates.
14. Depending on the chosen authentication method, different encryption algorithms may or may not be supported for storage of the passwords in the user database. A table showing some of the authentication methods with the supported algorithms is here: http://deployingradius.com/documents/protocols/compatibility.html

Support / Knowledge places

Most A lot of documentation regarding FreeRADIUS and many modules, and some examples, can be found on the FreeRADIUS wiki:

https://wiki.freeradius.org/

This document also seems to be good, and describes '@@@'FreeRADIUS technical guide:

https://networkradius.com/doc/FreeRADIUS%20Technical%20Guide.pdf

...

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.

Another good site (linked to in FreeRADIUS wiki):

http://deployingradius.com 

Page with information on finding documentation / support:

https://freeradius.org/documentation/

Sources

https://en.wikipedia.org/wiki/IEEE_802.1X

...