I'll try to keep this as simple as I can. I am using FreeRADIUS 2.2.8. When I set the "Session-Timeout := 600" for a user, the NAS is supposed to renew the session every 10 minutes. My Unifi AP recognises the attribute and actually DOES terminate the first session when it times out after 10 minutes. The problem is that it terminates only the first session, the second session lasts until the NAS reboots, the user logs out or shuts down the host. This means a user could exceed his quota if he keeps his wireless connection alive. There are some users that exceed their 7GB weekly quota by 6 GBs! Should I blame the AP firmware for this or is it a bug in FreeRADIUS 2.2.8? NB: I could send more detailed TCPDUMP and MySQL information for those who are interested. Thank you in advance. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 02/02/2017 09:24, Selahattin Cilek wrote:
When I set the "Session-Timeout := 600" for a user, the NAS is supposed to renew the session every 10 minutes. My Unifi AP recognises the attribute and actually DOES terminate the first session when it times out after 10 minutes. The problem is that it terminates only the first session, the second session lasts until the NAS reboots, the user logs out or shuts down the host. This means a user could exceed his quota if he keeps his wireless connection alive. There are some users that exceed their 7GB weekly quota by 6 GBs! Should I blame the AP firmware for this or is it a bug in FreeRADIUS 2.2.8?
That's very easy to determine. Use tcpdump / wireshark / radsniff to capture all the response from FreeRADIUS. - If FreeRADIUS *is* sending the Session-Timeout every time, then the bug is in the access point. - If FreeRADIUS *isn't* sending the Session-Timeout attribute sometimes, then the bug is in FreeRADIUS (or the way you have configured it) However, I would point out that there are much better ways of achieving your goal than kicking off users every 10 minutes, which is highly disruptive. 1. Use Radius Accounting to measure how much traffic users are using (with Interim-Accounting you will get periodic updates). Then kick the user off when the user reaches the download limit. Unifi provides an HTTP/JSON API to do this. This shell script shows how to use it: https://www.ubnt.com/downloads/unifi/5.3.11/unifi_sh_api "unifi_reconnect_sta" will kick off the user, to force them to reauthenticate. 2. The Unifi controller's mongodb database tracks how much bandwidth every user has consumed. So you could just periodically query that and kick off the abusers. 3. Use the Unifi's built-in bandwidth control features (User Groups / bandwidth limits). That's at the level of kbps not total GB per week. Still, people who have exceeded their quota could have a very low bandwidth limit applied. Regards, Brian.
Brian Chandler wrote:
However, I would point out that there are much better ways of achieving your goal than kicking off users every 10 minutes, which is highly disruptive.
This is something I've been wondering and wishing for the time/motivation to look into. It's not necessarily incumbent on the NAS to kill the client's connection *before* the re-auth as long as they will definitely kill it without a successful reauth and they make the Session-Timeout deadline; some NAS vendors may have used the wiggle room here to keep the client traffic flowing during the re-authentication and on a success just keep them working. Surveying that behavior across popular NAS units would be interesting. But, that does not necessarily mean even when attached to those products that clients will play ball... so before even that, surveying which clients might perform a hitless reauth (both during EAP, and during DHCP if it is triggered) or measuring the magnitude of the hit would be the better first step. Also there is EAP-ERP (RFC 5296/6696) to streamline such behavior; I haven't gone digging to see if any products claim support for it.
Without some sort of mechanism to periodically update and check network usage, it is impossible to enforce quota on the users. It would be impossible for the NAS to keep long-term track of network usage by hundreds of users, and therefore it is FreeRADIUS's job to do that. On 02.02.2017 18:39, Brian Julin wrote:
Brian Chandler wrote:
However, I would point out that there are much better ways of achieving your goal than kicking off users every 10 minutes, which is highly disruptive. This is something I've been wondering and wishing for the time/motivation to look into.
It's not necessarily incumbent on the NAS to kill the client's connection *before* the re-auth as long as they will definitely kill it without a successful reauth and they make the Session-Timeout deadline; some NAS vendors may have used the wiggle room here to keep the client traffic flowing during the re-authentication and on a success just keep them working. Surveying that behavior across popular NAS units would be interesting.
But, that does not necessarily mean even when attached to those products that clients will play ball... so before even that, surveying which clients might perform a hitless reauth (both during EAP, and during DHCP if it is triggered) or measuring the magnitude of the hit would be the better first step.
Also there is EAP-ERP (RFC 5296/6696) to streamline such behavior; I haven't gone digging to see if any products claim support for it.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Feb 2, 2017, at 10:59 AM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:
Without some sort of mechanism to periodically update and check network usage, it is impossible to enforce quota on the users. It would be impossible for the NAS to keep long-term track of network usage by hundreds of users
No. Some vendors do it. it's just 8 bytes of data in a session structure on the NAS. Alan DeKok.
Do you know any makers of APs that have no issues with RADIUS accounting? On 02.02.2017 19:01, Alan DeKok wrote:
On Feb 2, 2017, at 10:59 AM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:
Without some sort of mechanism to periodically update and check network usage, it is impossible to enforce quota on the users. It would be impossible for the NAS to keep long-term track of network usage by hundreds of users No.
Some vendors do it. it's just 8 bytes of data in a session structure on the NAS.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Without some sort of mechanism to periodically update and check network usage, it is impossible to enforce quota on the users. It would be impossible for the NAS to keep long-term track of network usage by hundreds of users, and therefore it is FreeRADIUS's job to do that. On 02.02.2017 18:39, Brian Julin wrote:
Brian Chandler wrote:
However, I would point out that there are much better ways of achieving your goal than kicking off users every 10 minutes, which is highly disruptive. This is something I've been wondering and wishing for the time/motivation to look into.
It's not necessarily incumbent on the NAS to kill the client's connection *before* the re-auth as long as they will definitely kill it without a successful reauth and they make the Session-Timeout deadline; some NAS vendors may have used the wiggle room here to keep the client traffic flowing during the re-authentication and on a success just keep them working. Surveying that behavior across popular NAS units would be interesting.
But, that does not necessarily mean even when attached to those products that clients will play ball... so before even that, surveying which clients might perform a hitless reauth (both during EAP, and during DHCP if it is triggered) or measuring the magnitude of the hit would be the better first step.
Also there is EAP-ERP (RFC 5296/6696) to streamline such behavior; I haven't gone digging to see if any products claim support for it.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Brian Candler -
Brian Julin -
Selahattin Cilek