-------- Forwarded Message -------- Subject: Re: Session-Timeout Problem Date: Thu, 2 Feb 2017 15:17:00 +0300 From: Selahattin ÇİLEK <selahattin_cilek@hotmail.com><mailto:selahattin_cilek@hotmail.com> To: Brian Candler <b.candler@pobox.com><mailto:b.candler@pobox.com> On 02.02.2017 13:45, Brian Candler wrote: 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) I don't believe FreeRADIUS is supposed to send Session-Timeout messages the to NAS, but the other way around. 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. No, it is not disruptive. The NAS is not supposed to first disconnect and then reconnect the user every 10 minutes, it is supposed to send usage statistics and request a re-authentication of the user. I have a script that checks network usage and decides whether or not to allow the user to be re-authenticated: Exec-Program-Wait = /usr/local/bin/bash /usr/local/etc/raddb/scripts/sql_datacounter_auth.sh scilek I need to keep track of network usage using FreeRADIUS and MySQL. 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. The "Acct-Interim-Interval" informs the NAS of how frequently it should send update packets to the FreeRADIUS server and send the usage statistics incrementally. A user cannot be re-authenticated using this attribute. The updates do not occur during the second session anyway. The key is the "Session-Timeout" attribute. A user can be granted or denied access only before a new session starts. 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 I do not want to use vendor scripts. I want to use FreeRADIUS, MySQL and my own scripts. "unifi_reconnect_sta" will kick off the user, to force them to reauthenticate. A NAS based solution will not work because I will have to configure each and every NAS on each and every site. What if I'd like to use some other NAS some other day? 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. I cannot have a separate machine for Unifi controller on the site. Besides, I might someday wanna keep track of network usage in a centralised database. 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. That will not work because it is not centralised. I have 30 APs on one site and the user can log in to any one of them. Regards, Brian. Thank you very much for the advice. ________________________________ [Avast logo] <https://www.avast.com/antivirus> This email has been checked for viruses by Avast antivirus software. www.avast.com<https://www.avast.com/antivirus> ________________________________ [Avast logo] <https://www.avast.com/antivirus> This email has been checked for viruses by Avast antivirus software. www.avast.com<https://www.avast.com/antivirus>
Your mail client's lack of proper quoting makes your responses *really* hard to read. On Thu, Feb 02, 2017 at 12:48:14PM +0000, Selahattin Cilek wrote:
On 02.02.2017 13:45, Brian Candler wrote: 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)
I don't believe FreeRADIUS is supposed to send Session-Timeout messages the to NAS, but the other way around.
You don't believe correctly. You need to do what Brian suggested so you can find out what is happening.
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.
No, it is not disruptive. The NAS is not supposed to first disconnect and then reconnect the user every 10 minutes, it is supposed to send usage statistics and request a re-authentication of the user. I have a script that checks network usage and decides whether or not to allow the user to be re-authenticated: Exec-Program-Wait = /usr/local/bin/bash /usr/local/etc/raddb/scripts/sql_datacounter_auth.sh scilek I need to keep track of network usage using FreeRADIUS and MySQL.
The stats you want should come in the Accounting Interim-Updates, as Brian said. You don't *need* to kick everyone off every 10 minutes.
A NAS based solution will not work because I will have to configure each and every NAS on each and every site. What if I'd like to use some other NAS some other day?
Then you configure it. Like you have to configure everything you use. But as to the original problem - look at the FreeRADIUS -X debug output to see what is happening. Otherwise everyone is just guessing. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
I do not want to turn this into a clash of egos, I just want to understand the problem and solve it. This is what I want to achieve: I want to keep user data and statistics in a MySQL database. I want to enforce quota based on the data received by FreeRADIUS 2.2.8 from any NAS. This is my plan: The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers. This is my problem: The NAS receives and recognises the "Session-Timeout" attribute. It authenticates the user and starts counting data. A row is inserted into the "radacct" table. At the end of the first session, the row is updated with the fields: acctsessiontime -> 600 (the same as the Session-Timeout attribute) acctinputoctets -> whatever the user has uploaded acctaoutputoctets -> whatever the user has downloaded acctterminatecause -> Session-Timeout Then the user is authenticated a second time, and therefore a second row is inserted into the radacct table, with an incremented session ID, of course. But strangely, this session never expires and is never updated through Acct-Interim-Updates attribute. The second session lasts forever; that is, until the user turns off WiFi or shuts down his machine. I believe this explains what happens between the NAS and FreeRADIUS: SELECT * FROM radacct; radacctid acctsessionid acctuniqueid username groupname realm nasipaddress nasportid nasporttype acctstarttime acctstoptime acctsessiontime acctauthentic connectinfo_start connectinfo_stop acctinputoctets acctoutputoctets calledstationid callingstationid acctterminatecause servicetype framedprotocol framedipaddress acctstartdelay acctstopdelay xascendsessionsvrkey 1 5892F172-00000000 06aefeead5872f8f scilek 192.168.2.3 0 Wireless-802.11 "2017-02-02 11:45:09" "2017-02-02 11:55:09" 600 RADIUS "CONNECT 0Mbps 802.11b" "CONNECT 0Mbps 802.11b" 34296191 34667792 80-2A-A8-AD-1E-F9:SCILEK.NET 00-22-FA-F5-B9-0A Session-Timeout 0 0 2 5892F172-00000001 19d67f917a5dbc29 scilek 192.168.2.3 0 Wireless-802.11 "2017-02-02 11:55:09" "2017-02-02 12:25:13" 1804 RADIUS "CONNECT 0Mbps 802.11b" "CONNECT 0Mbps 802.11b" 89525790 86476588 80-2A-A8-AD-1E-F9:SCILEK.NET 00-22-FA-F5-B9-0A User-Request 0 0 Here are my questions: Why does the NAS terminate the first session as it is supposed to but not the second one? Who is supposed to inform who when the session is over? Is the NAS supposed to keep track of this and inform FreeRADIUS, or the other way around? Doesn't the idea of FreeRADIUS keeping track of session time and telling the NAS to terminate the user's session go against the design philosophy of RADIUS? Isn't RADIUS only supposed to inform and not enforce? Who is to blame if the session is not terminated when it should? Is there anything I can do with the FreeRADIUS configuration to make that NAS terminate the second session and start the third and so on? Is this a FreeRADIUS configuration issue or is there a bug in the AP firmware? Thank you all. ________________________________ [Avast logo] <https://www.avast.com/antivirus> This email has been checked for viruses by Avast antivirus software. www.avast.com<https://www.avast.com/antivirus>
On Feb 2, 2017, at 9:26 AM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:
I do not want to turn this into a clash of egos, I just want to understand the problem and solve it.
That's best done by keeping things technical.
This is what I want to achieve: I want to keep user data and statistics in a MySQL database. I want to enforce quota based on the data received by FreeRADIUS 2.2.8 from any NAS.
Some NAS vendors support that via VSAs, but it's rare. Consult your NAS documentation to see what it supports. If they don't support that, perhaps the NAS supports Disconnect-Request attributes. Again, consult your NAS documentation to see. If both of those aren't supported by the NAS, your only choice is to set a low Session-Timeout. You can calculate the limit (not 10 minutes...) by calculating their bandwidth limit, and dividing that by the speed of their line. Then, send that as Session-Timeout. When they reconnect, do the same calculation.
This is my plan: The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers.
That's all fine.
This is my problem: The NAS receives and recognises the "Session-Timeout" attribute. It authenticates the user and starts counting data. A row is inserted into the "radacct" table. At the end of the first session, the row is updated with the fields: acctsessiontime -> 600 (the same as the Session-Timeout attribute) acctinputoctets -> whatever the user has uploaded acctaoutputoctets -> whatever the user has downloaded acctterminatecause -> Session-Timeout
Then the user is authenticated a second time, and therefore a second row is inserted into the radacct table, with an incremented session ID, of course. But strangely, this session never expires and is never updated through Acct-Interim-Updates attribute. The second session lasts forever; that is, until the user turns off WiFi or shuts down his machine.
If FreeRADIUS sends the same attributes in the Access-Accept for both sessions, the only conclusion is that your NAS is broken. Throw it in the garbage and buy one that works. Ideally, one which supports Disconnect-Request.
Why does the NAS terminate the first session as it is supposed to but not the second one?
Ask the NAS vendor how their equipment works.
Who is supposed to inform who when the session is over?
FreeRADIUS, via Session-Timeout.
Is the NAS supposed to keep track of this and inform FreeRADIUS, or the other way around?
The NAS knows the session timeout only because it's sent in a RADIUS packet.
Doesn't the idea of FreeRADIUS keeping track of session time and telling the NAS to terminate the user's session go against the design philosophy of RADIUS?
Yes. The problem is you don't really want a session timeout. You want a bandwidth limit. And that isn't part of standard RADIUS.
Isn't RADIUS only supposed to inform and not enforce?
Yes. The RADIUS server tells the NAS something, and the NAS should behave as instructed.
Who is to blame if the session is not terminated when it should?
The NAS.
Is there anything I can do with the FreeRADIUS configuration to make that NAS terminate the second session and start the third and so on?
No. No amount of poking FreeRADIUS will make the NAS behave properly.
Is this a FreeRADIUS configuration issue or is there a bug in the AP firmware?
It's a bug in the NAS. Throw it in the garbage and buy one that works. Alan DeKok.
On 02/02/2017 14:40, Alan DeKok wrote:
Who is supposed to inform who when the session is over? FreeRADIUS, via Session-Timeout. For clarity: FreeRADIUS says at the *start* of the session that the time limit is 10 minutes.
But when that time is over - or sooner if the user terminates the session - it is the NAS which sends an Accounting-Stop packet. Assuming the user then tries to re-establish their session, the NAS will also send a fresh Access-Request. So it is the NAS which informs FreeRADIUS of the end of the session, and also that the user wants to start a new session.
Is the NAS supposed to keep track of this and inform FreeRADIUS, or the other way around? The NAS knows the session timeout only because it's sent in a RADIUS packet.
And again for clarity, it is the NAS's responsibility to enforce the session limit, i.e. to actually disconnect the user after 10 minutes. It's then a by-product of session termination that it sends the Accounting-Stop packet.
This is what I have been expecting for quite some time, but I was hoping you wouldn't take it to such extremes as dumping thousands of dollars' worth of fine equipment. The logic dictates that the NAS learn what it is supposed to do from FreeRADIUS and behave accordingly. I have already contacted with Ubiquiti Networks PR and I believe their firmware development have confirmed this to be a bug in the firmware. They said they were going to address the issue. Thank you all very much. On 02.02.2017 17:40, Alan DeKok wrote:
On Feb 2, 2017, at 9:26 AM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:
I do not want to turn this into a clash of egos, I just want to understand the problem and solve it. That's best done by keeping things technical.
This is what I want to achieve: I want to keep user data and statistics in a MySQL database. I want to enforce quota based on the data received by FreeRADIUS 2.2.8 from any NAS. Some NAS vendors support that via VSAs, but it's rare. Consult your NAS documentation to see what it supports.
If they don't support that, perhaps the NAS supports Disconnect-Request attributes. Again, consult your NAS documentation to see.
If both of those aren't supported by the NAS, your only choice is to set a low Session-Timeout. You can calculate the limit (not 10 minutes...) by calculating their bandwidth limit, and dividing that by the speed of their line. Then, send that as Session-Timeout. When they reconnect, do the same calculation.
This is my plan: The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers. That's all fine.
This is my problem: The NAS receives and recognises the "Session-Timeout" attribute. It authenticates the user and starts counting data. A row is inserted into the "radacct" table. At the end of the first session, the row is updated with the fields: acctsessiontime -> 600 (the same as the Session-Timeout attribute) acctinputoctets -> whatever the user has uploaded acctaoutputoctets -> whatever the user has downloaded acctterminatecause -> Session-Timeout
Then the user is authenticated a second time, and therefore a second row is inserted into the radacct table, with an incremented session ID, of course. But strangely, this session never expires and is never updated through Acct-Interim-Updates attribute. The second session lasts forever; that is, until the user turns off WiFi or shuts down his machine. If FreeRADIUS sends the same attributes in the Access-Accept for both sessions, the only conclusion is that your NAS is broken. Throw it in the garbage and buy one that works. Ideally, one which supports Disconnect-Request.
Why does the NAS terminate the first session as it is supposed to but not the second one? Ask the NAS vendor how their equipment works.
Who is supposed to inform who when the session is over? FreeRADIUS, via Session-Timeout.
Is the NAS supposed to keep track of this and inform FreeRADIUS, or the other way around? The NAS knows the session timeout only because it's sent in a RADIUS packet.
Doesn't the idea of FreeRADIUS keeping track of session time and telling the NAS to terminate the user's session go against the design philosophy of RADIUS? Yes.
The problem is you don't really want a session timeout. You want a bandwidth limit. And that isn't part of standard RADIUS.
Isn't RADIUS only supposed to inform and not enforce? Yes. The RADIUS server tells the NAS something, and the NAS should behave as instructed.
Who is to blame if the session is not terminated when it should? The NAS.
Is there anything I can do with the FreeRADIUS configuration to make that NAS terminate the second session and start the third and so on? No.
No amount of poking FreeRADIUS will make the NAS behave properly.
Is this a FreeRADIUS configuration issue or is there a bug in the AP firmware? It's a bug in the NAS. Throw it in the garbage and buy one that works.
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
On Feb 2, 2017, at 9:59 AM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:
This is what I have been expecting for quite some time, but I was hoping you wouldn't take it to such extremes as dumping thousands of dollars' worth of fine equipment.
20 years of experience shows that answer is the best one to convince people that the problem isn't FreeRADIUS. If we say "upgrade your NAS", we get responses of "there's no newer firmware", or "the vendor is out of business", etc. i.e. pretty much any other answer gets excuses, evasions, and continued blaming of FreeRADIUS. No, it's not FreeRADIUS. It's the NAS.
The logic dictates that the NAS learn what it is supposed to do from FreeRADIUS and behave accordingly. I have already contacted with Ubiquiti Networks PR and I believe their firmware development have confirmed this to be a bug in the firmware. They said they were going to address the issue.
That would be good. Alan DeKok.
Hi,
I do not want to turn this into a clash of egos, I just want to understand the problem and solve it.
okay - you were given advice which you've rejected because you want to do things your way - fair enough, so you need to follow the obvious bit of advice - capture the RADIUS conversation that occurs when the reauth is occuring..... its likely that its eg cached auth and you are not putting that attribute into cache so a basic authntication is okay is being returned with no session timeout. or its a bug with your NAS...in which case you wont need to do anything special if you changed to a different NAS ;-)
This is what I want to achieve: I want to keep user data and statistics in a MySQL database. I want to enforce quota based on the data received by FreeRADIUS 2.2.8 from any NAS.
basic stuff. just accounting from NAS to a DB
The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers.
no, you use CoA or the NAS API to control the users...you dont constantly reauth people for this functionality. then you can drop them as soon as they reach $threshold, rather than up to 10 minutes later also, if you reauth then its a new session....so you'll get loads of sessions to deal with. alan
"its likely that its eg cached auth and you are not putting that attribute into cache so a basic authntication is okay is being returned with no session timeout." Yes, I have indeed enabled session caching in my eap.conf file: cache { enable = yes lifetime = 24 max_entries = 1024 } Is that why the second session never terminates? How can I put the "Session-Timeout" attribute into the session cache? On 02.02.2017 17:50, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I do not want to turn this into a clash of egos, I just want to understand the problem and solve it. okay - you were given advice which you've rejected because you want to do things your way - fair enough, so you need to follow the obvious bit of advice - capture the RADIUS conversation that occurs when the reauth is occuring..... its likely that its eg cached auth and you are not putting that attribute into cache so a basic authntication is okay is being returned with no session timeout.
or its a bug with your NAS...in which case you wont need to do anything special if you changed to a different NAS ;-)
This is what I want to achieve: I want to keep user data and statistics in a MySQL database. I want to enforce quota based on the data received by FreeRADIUS 2.2.8 from any NAS. basic stuff. just accounting from NAS to a DB
The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers. no, you use CoA or the NAS API to control the users...you dont constantly reauth people for this functionality.
then you can drop them as soon as they reach $threshold, rather than up to 10 minutes later
also, if you reauth then its a new session....so you'll get loads of sessions to deal with.
alan - 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
On Thu, Feb 02, 2017 at 04:31:49PM +0000, Selahattin Cilek wrote:
"its likely that its eg cached auth and you are not putting that attribute into cache so a basic authntication is okay is being returned with no session timeout."
Yes, I have indeed enabled session caching in my eap.conf file: cache { enable = yes lifetime = 24 max_entries = 1024 }
Is that why the second session never terminates? How can I put the "Session-Timeout" attribute into the session cache?
Do you know yet whether it actually *is* sending Session-Timeout or not at reauth time? i.e. have you run FreeRADIUS in debug mode, or used radsniff? If it is sending it, then you need to look at the NAS and your FreeRADIUS config is good already. If not, then you need to look at the FreeRADIUS config. But you probably don't need to cache it - it's the same every time. Just make sure it's in the correct place in the config (likely post-auth) so it's always returned. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
How do I implement a Cached-Session-Policy and how do I make sure that the Session-Timeout attribute is included? On 02.02.2017 19:31, Selahattin ÇİLEK wrote:
"its likely that its eg cached auth and you are not putting that attribute into cache so a basic authntication is okay is being returned with no session timeout."
Yes, I have indeed enabled session caching in my eap.conf file: cache { enable = yes lifetime = 24 max_entries = 1024 }
Is that why the second session never terminates? How can I put the "Session-Timeout" attribute into the session cache?
On 02.02.2017 17:50, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I do not want to turn this into a clash of egos, I just want to understand the problem and solve it. okay - you were given advice which you've rejected because you want to do things your way - fair enough, so you need to follow the obvious bit of advice - capture the RADIUS conversation that occurs when the reauth is occuring..... its likely that its eg cached auth and you are not putting that attribute into cache so a basic authntication is okay is being returned with no session timeout.
or its a bug with your NAS...in which case you wont need to do anything special if you changed to a different NAS ;-)
This is what I want to achieve: I want to keep user data and statistics in a MySQL database. I want to enforce quota based on the data received by FreeRADIUS 2.2.8 from any NAS. basic stuff. just accounting from NAS to a DB
The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers. no, you use CoA or the NAS API to control the users...you dont constantly reauth people for this functionality.
then you can drop them as soon as they reach $threshold, rather than up to 10 minutes later
also, if you reauth then its a new session....so you'll get loads of sessions to deal with.
alan - 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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Hi,
How do I implement a Cached-Session-Policy and how do I make sure that the Session-Timeout attribute is included?
wait. are you sure thats even your problem? have you captured the RADIUS packets to see the content when the re-auth is sent? if you have, and that attribute is missing then 1) you can send the attribute back all the time (add it to reply in the post-auth section of the outer tunnel 2) read the cache docs and look at provided config (if you havent stripped it all out) that shows how to add attributes into the cache system and how to apply those cached values to the outer reply alan
On 02.02.2017 21:20, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
How do I implement a Cached-Session-Policy and how do I make sure that the Session-Timeout attribute is included? wait. are you sure thats even your problem? have you captured the RADIUS packets to see the content when the re-auth is sent? Yes, I have captured and checked RADIUS authentication and accounting packets three times: tcpdump -n -vvv -i em1 src or dst host 192.168.2.1 or 192.168.2.3 and src or dst port 1812 or 1813
The Session-Timeout appears at the beginning of the 1st session only: "Session Timeout Attribute (27), length: 6, Value: 10:00 min" I have also disabled EAP session caching with the exact same outcome.
if you have, and that attribute is missing then
That attribute is missing in the Access Accept of the second session.
1) you can send the attribute back all the time (add it to reply in the post-auth section of the outer tunnel
There is no "outer-tunnel" in "sites-available", even if there were one, I wouldn't know how to add it.
2) read the cache docs and look at provided config (if you havent stripped it all out) that shows how to add attributes into the cache system and how to apply those cached values to the outer reply
I don't know where the cache docs are and would gladly read them if you could direct me.
alan - 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
On Feb 2, 2017, at 1:30 PM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote: the RADIUS
packets to see the content when the re-auth is sent? Yes, I have captured and checked RADIUS authentication and accounting packets three times: tcpdump -n -vvv -i em1 src or dst host 192.168.2.1 or 192.168.2.3 and src or dst port 1812 or 1813
The Session-Timeout appears at the beginning of the 1st session only: "Session Timeout Attribute (27), length: 6, Value: 10:00 min"
Then you configured the server to only send Session-Timeout on the first packet. The server does NOT send Session-Timeout by default. So if it does... you edited it. If the server sends Session-Timeout at the wrong time... you told it to send Session-Timeout at the wrong time. Go back and read the debug output. Look at it across multiple sessions. If you can't do this in production, build a test system. It won't cost anything. Then, configure the server to send Session-Timeout correctly. I'll note that in all of this, you don't describe what you want to do. You ask how to fix a particular problem. This is usually the wrong approach. If you describe what you want and what you have, we can probably suggest a solution that will work. If you keep asking questions which may very well be irrelevant, we won't be able to help you. And we don't know if the questions are relevant (or not), because you're not describing what you want and what you have. Alan DeKok.
On 02.02.2017 22:23, Alan DeKok wrote:
On Feb 2, 2017, at 1:30 PM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote: the RADIUS
packets to see the content when the re-auth is sent? Yes, I have captured and checked RADIUS authentication and accounting packets three times: tcpdump -n -vvv -i em1 src or dst host 192.168.2.1 or 192.168.2.3 and src or dst port 1812 or 1813
The Session-Timeout appears at the beginning of the 1st session only: "Session Timeout Attribute (27), length: 6, Value: 10:00 min" Then you configured the server to only send Session-Timeout on the first packet.
The server does NOT send Session-Timeout by default. So if it does... you edited it. If the server sends Session-Timeout at the wrong time... you told it to send Session-Timeout at the wrong time.
Go back and read the debug output. Look at it across multiple sessions. If you can't do this in production, build a test system. It won't cost anything.
Then, configure the server to send Session-Timeout correctly.
I'll note that in all of this, you don't describe what you want to do. You ask how to fix a particular problem. This is usually the wrong approach. If you describe what you want and what you have, we can probably suggest a solution that will work.
If you keep asking questions which may very well be irrelevant, we won't be able to help you. And we don't know if the questions are relevant (or not), because you're not describing what you want and what you have.
Alan DeKok.
I set up my test network three weeks ago and I have been trying to solve this problem since. I just want to find out how to configure FreeRADIUS to communicate the Session-Timeout attribute every time a session is renewed. This is important because that is when I can intervene and make FreeRADIUS decide whether or not to let the user continue using the network thanks to a script I have written myself: "Exec-Program-Wait = /usr/local/bin/bash /usr/local/etc/raddb/scripts/sql_datacounter_auth.sh scilek" (Abbreviated from the radreply table...) This script runs at the beginning of each session and checks whether or not the user has reached his quota. If he has, he is denied access: # ... # Code dismissed for the sake of brevity... # Check if the user has used up his/her quota: if (( $DOWNLOAD < $QUOTA )); then logger -f /var/log/system.log "ACCEPTED: $USERNAME $DOWNLOAD_MB $QUOTA_MB $PERIOD" exit 0 else logger -f /var/log/system.log "DENIED: $USERNAME $DOWNLOAD_MB $QUOTA_MB $PERIOD" exit 99 fi I have not chosen to achieve my goal using the Acct-Interim-Interval attribute because I don't know how to make FreeRADIUS react upon receiving an interim update packet. Even if I did, I would not know how to make the NAS terminate the user's session. I agree I might not have been verbose enough so far, but you'll agree I could not post all the data related to the issue. I know people do not like to read lots of cryptic messages, and I hoped you would fill in the gaps. Thank you all for your interest. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Feb 2, 2017, at 3:02 PM, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:
I set up my test network three weeks ago and I have been trying to solve this problem since. I just want to find out how to configure FreeRADIUS to communicate the Session-Timeout attribute every time a session is renewed.
In post-auth: update reply { Session-Timeout := 3600 } Will set it to 3600 for every Access-Accept. What's so hard about that? And why aren'y you describing HOW you're currently setting Session-Timeout? You're working very hard to give only vague hints about what you're doing. The more vague your messages, the more vague the answers, and the less we can help you. Your configuration isn't a secret. It does what 1,000,000 other systems do. Explain what you're doing, and post the debug log (honestly, what's the problem with that?). If you can't do that, you won't get the problem fixed.
This script runs at the beginning of each session and checks whether or not the user has reached his quota. If he has, he is denied access:
You can write all that in unlang.
I have not chosen to achieve my goal using the Acct-Interim-Interval attribute because I don't know how to make FreeRADIUS react upon receiving an interim update packet.
Really? Just read the debug log, and see what it does when it receives an interim update packet. The information you need to solve the problem is in front of you. You're working VERY hard to avoid solving the problem.
Even if I did, I would not know how to make the NAS terminate the user's session.
The NAS should have documentation. Go read it. It's not hard.
I agree I might not have been verbose enough so far, but you'll agree I could not post all the data related to the issue.
I don't agree. You could have given a LOT more useful information. Your messages have been cryptic and minimal.
I know people do not like to read lots of cryptic messages, and I hoped you would fill in the gaps.
So stop posting cryptic messages. It's like playing 20 questions. You post a message which is vague and based on incorrect assumptions, and then wonder why we're having a hard time helping you. Read the debug log. Read the documentation. If you can't do that, well, you'll never solve the problem. Alan DeKok.
I ran the server in debug mode and captured the packets transferred between FreeRADIUS and NAS. I turned my Windows 7 laptop on ran the command: ping 192.168.2.1 -t -l 65500 and then waited for 21 minutes to pass. Then I shut down the laptop. I have attached 3 files: tcpdump.txt, debug.txt and mysql.txt. I believe this should be more than enough to understand what is going on, but I don't know where to look. Thank you all in advance. On 02.02.2017 23:01, Selahattin ÇİLEK wrote:
tcpdump -n -vvv -i em1 src or dst host 192.168.2.1 or 192.168.2.3 and src or dst port 1812 or 1813
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
It is possible to inject the Session-Timeout attribute into Account Request packets? If yes, how? On 03.02.2017 06:23, Selahattin Cilek wrote: I ran the server in debug mode and captured the packets transferred between FreeRADIUS and NAS. I turned my Windows 7 laptop on ran the command: ping 192.168.2.1 -t -l 65500 and then waited for 21 minutes to pass. Then I shut down the laptop. I have attached 3 files: tcpdump.txt, debug.txt and mysql.txt. I believe this should be more than enough to understand what is going on, but I don't know where to look. Thank you all in advance. On 02.02.2017 23:01, Selahattin ÇİLEK wrote: tcpdump -n -vvv -i em1 src or dst host 192.168.2.1 or 192.168.2.3 and src or dst port 1812 or 1813 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ________________________________ [Avast logo] <https://www.avast.com/antivirus> This email has been checked for viruses by Avast antivirus software. www.avast.com<https://www.avast.com/antivirus>
After sifting through a wealth of diagnostic messages, I have come to the conclusion that the NAS is the source of the problem. The Session-Timeout attribute appears in Access-Accept and Access-Challenge packets only. The NAS is supposed to keep the value of this attribute in mind for as long as the user is connected, but upon termination of the first session, it discards the the attribute. After the first session, there are only Accounting-Start and Accounting-Stop requests sent from the NAS to FreeRADIUS, and there is no way for FreeRADIUS to remind the NAS of the Session-Timeout attribute. I am convinced that the problem is in the AP firmware. Thank you all for the advice. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 03/02/2017 08:40, Selahattin Cilek wrote:
It is possible to inject the Session-Timeout attribute into Account Request packets? If yes, how?
The Session-Timeout is an instruction *from* the RADIUS server *to* the NAS, telling the NAS how long it is allowed to leave the user connected. That's why it goes in Access-Accept. There's no particular reason for the Session-Timeout to be included in the Accounting-Request. RFC2866 does allow it, but it would be a for information only ("I have been told to disconnect the user after they have been online for X seconds") For one last time, here's how it works. 1. NAS sends Access-Request. << at this point, for EAP there's a series of Access-Challenge/Access-Response exchanges >> 2. RADIUS server sends Access-Accept containing Session-Timeout (see RFC2865 section 5.27 and 5.44) 3. NAS grants access to the user and starts a timer. 4. NAS sends Accounting-Request (Start). It may also subsequently send Accounting-Request (Interim-Update) periodically. 5. NAS disconnects the user after the time given in Session-Timeout has expired. 6. NAS sends Accounting-Request (Stop). 7. Go back to step 1 In steps 4 and 6, the RADIUS server confirms receipt of the Accounting-Request messages with Accounting-Response messages, but those contain no content. There are no other RADIUS messages involved.
Yes, it was careless of me to post that question without carefully examining the direction of the packets. Thank you for the information. At least I now know where the fault is. I hope the UBNT guys will soon solve this problem. On 03.02.2017 13:23, Brian Candler wrote:
On 03/02/2017 08:40, Selahattin Cilek wrote:
It is possible to inject the Session-Timeout attribute into Account Request packets? If yes, how?
The Session-Timeout is an instruction *from* the RADIUS server *to* the NAS, telling the NAS how long it is allowed to leave the user connected. That's why it goes in Access-Accept.
There's no particular reason for the Session-Timeout to be included in the Accounting-Request. RFC2866 does allow it, but it would be a for information only ("I have been told to disconnect the user after they have been online for X seconds")
For one last time, here's how it works.
1. NAS sends Access-Request.
<< at this point, for EAP there's a series of Access-Challenge/Access-Response exchanges >>
2. RADIUS server sends Access-Accept containing Session-Timeout (see RFC2865 section 5.27 and 5.44)
3. NAS grants access to the user and starts a timer.
4. NAS sends Accounting-Request (Start). It may also subsequently send Accounting-Request (Interim-Update) periodically.
5. NAS disconnects the user after the time given in Session-Timeout has expired.
6. NAS sends Accounting-Request (Stop).
7. Go back to step 1
In steps 4 and 6, the RADIUS server confirms receipt of the Accounting-Request messages with Accounting-Response messages, but those contain no content. There are no other RADIUS messages involved.
- 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
Hi,
1) you can send the attribute back all the time (add it to reply in the post-auth section of the outer tunnel There is no "outer-tunnel" in "sites-available", even if there were one, I wouldn't know how to add it.
well, yes there is, its usually called 'default' by default.
2) read the cache docs and look at provided config (if you havent stripped it all out) that shows how to add attributes into the cache system and how to apply those cached values to the outer reply I don't know where the cache docs are and would gladly read them if you could direct me.
sites-enabled/default, sites-enabled/inner-tunnel conatin all the info needed regarding the cache and updating replies but if this is still ocrruign even when you dont have cache running, you will need to do, as instructed already like 4 times, to run in debug mode and see what the server is doing/deciding. it will be quite clear. alan
I have to admit I haven't read every single email in this thread, so perhaps I've missed a requirement or nuance, but why do you need to use Session-Timeout for this? Why not use alive (also called interim) radius accounting records and act on them when received? That's trivial to do. Once the quota is reached then send a COA to the NAS to terminate the session. You'll also need some quota check during AA to keep a new session from being started. This can be done in a NAS independent kind of way. Bill On 2/2/2017 8:26 AM, Selahattin Cilek wrote:
This is my plan: The NAS regularly informs FreeRADIUS how much a user has been using the network. FreeRADIUS keeps the data in a MySQL database and regularly checks if the user has reached his quota. When a user reaches his quota, it tells the NAS not to let him use the network. In order to be able to grant or deny access to a user, the NAS is supposed to ask FreeRADIUS at regular intervals what to with the authentication request. The only way the NAS can know about these intervals is through the "Session-Timeout" attribute. At the end of each session, the NAS sends FreeRADIUS a packet that contains data about how much bandwidth the user has consumed. FreeRADIUS commits the to a local MySQL schema, which I have programmed to update some other custom tables through triggers.
On 02/02/2017 12:48, Selahattin Cilek wrote:
I don't believe FreeRADIUS is supposed to send Session-Timeout messages the to NAS, but the other way around. The AP sends an Access-Request, FreeRADIUS responds with Access-Accept.
The Session-Timeout attribute appears in the Access-Accept response.
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. No, it is not disruptive. The NAS is not supposed to first disconnect and then reconnect the user every 10 minutes,
Unfortunately, that's what you've told it to do with the Session-Timeout attribute. See RFC 2865, section 5.27 " This Attribute sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt. ... The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of seconds this user should be allowed to remain connected by the NAS." So the user will be kicked off and required to re-authenticate. If everything's working well, it may only be a second or two's loss of service, but that's what's happening.
A NAS based solution will not work because I will have to configure each and every NAS on each and every site.
Nope. The API request goes into the Unifi controller. It will automatically work out which AP the user is on, and kick them off it. (And you don't have to use their scripts; it's a simple JSON over HTTP POST which you can generate yourself. The script just gives you an example of the payload)
What if I'd like to use some other NAS some other day? Then indeed this approach won't work any more - but you did say you were using Unifi.
There is no standard way to kick off a user mid-session. Some devices might support a RADIUS CoA packet, some devices might support a SNMP set operation, some devices might have their own controller you can interact with, and some might have no way to do this at all.
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.
I cannot have a separate machine for Unifi controller on the site. Besides, I might someday wanna keep track of network usage in a centralised database.
The unifi controller gives you exactly that centralised database of usage. And it doesn't have to exist in the site. The software can run wherever you like, as long as it is reachable over the network. The software is free, and runs under Linux, Windows or OSX. It doesn't carry the user traffic, so if the controller shuts down for any reason, it doesn't affect the users. Neither does it affect authentication. You can even use Unifi's own cloud-hosted version of the service, if you buy one of their dongles: https://store.ubnt.com/unifi/unifi-cloud-key.html
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.
That will not work because it is not centralised. I have 30 APs on one site and the user can log in to any one of them.
On the controller, you set the limits at the user level. It doesn't matter which AP the user logs into, the controller takes care of it. I'm just saying: you've got a very nice product, you might want to use the capabilities it already has! Regards, Brian.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Bill Schoolfield -
Brian Candler -
Matthew Newton -
Selahattin Cilek