Re: Session-Timeout anomalies
Bill Isaacs wrote: Being a moderator does NOT give you moral license to treat people like children. The only moral issue here is you admitting you came here with the intention of trolling. The only purpose of this list is to help people solve problems. If that means reminding them to read the docs, so be it. If you want a friend, go somewhere else. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Session-Timeout anomalies
Hello all,
I'm researching this anomaly myself in all the documentation, but
thought it would also be helpful both to me and to others to post the
problem here.
SYMPTOM: Some Access-Period accounts (accounts which have X number of
seconds to continue logging in and out starting from the very first
login) are giving too much time -- that is, at some point they reload
the full value of the account type and restart the count down. I
discovered it while developing some interface code for our customer
service dept. So far, this DOES NOT seem to be happening to all
accounts. Moreover, the database info and radclient results are
inconsistent on these accounts that ARE showing the anomaly.
Here is an example of one such account, a development test account which
I created for debugging purposes. It's value is 30 days (2592000 seconds)
Radclient result:
===
# echo User-Name=cgitest,User-Password=cgitest | radclient -c 1 -n 3
-r 3 -t 3 -x 127.0.0.1:1812 auth -S shared
Sending Access-Request of id 24 to 127.0.0.1 port 1812
User-Name = cgitest
User-Password = cgitest
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=24,
length=26
Session-Timeout = 2366393
===
sql query:
SELECT IFNULL(TIME_TO_SEC(TIMEDIFF(NOW(), MIN(AcctStartTime))),0) FROM
radacct WHERE UserName='cgitest' ORDER BY AcctStartTime LIMIT 1 \g
+-+
| IFNULL(TIME_TO_SEC(TIMEDIFF(NOW(), MIN(AcctStartTime))),0) |
+-+
| 1447012 |
+-+
===
Ok, the problem here should be obvious but I'll explain these results
for those who are impatient. The Session-Timeout number is way too
large. As I stated previously, this is a 30 day account. It was counting
down with no problems until a few days ago. It then mysteriously began
reporting in the popup window which I was working on that it had 29.9
days left on it, after it had already counted down to something like 15
days. It simply seems to have reloaded itself, even though the sql query
reports the accurate number of seconds which have actually expired.
(1447012). So if we do the math: 2592000-1447012=1144988 (or roughly
13.25 days) should be the remaining time on this account. Not 27.38 days.
Here is the sql counter from sqlcounter.conf:
sqlcounter accessperiod {
counter-name = Max-Access-Period-Time
check-name = Access-Period
reply-name = Session-Timeout
sqlmod-inst = sql
key = User-Name
reset = never
query = “SELECT UNIX_TIMESTAMP() – UNIX_TIMESTAMP(AcctStartTime) FROM
radacct WHERE UserName = ‘%{%k}’ ORDER BY AcctStartTime LIMIT 1″
}
(Before anyone bitches about the sql query being different, save your
pixels -- no matter which style of query is used, the account reports
that it began at the same time, there is truly no issue here that I can
see).
ALSO, BEFORE YOU ASK: There is only 1 radius server and only 1 sql
server on the system. Besides, I have tested this exhaustively using
different things like the public IP, the fqdn, etc etc. Results are the
same - that is to say, wrong. lol
Ok so the question then is: where the hell is radclient getting the
notion that the account has 2366393 seconds left? Where is
Session-Timeout getting this information? Why is it only doing it on
some accounts and not others?
Any insights would be greatly appreciated. I will post the resolution
here (unless one of you smart lads or lasses beats me to it ;) ).
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
Ok so the question then is: where the hell is radclient getting the notion that the account has 2366393 seconds left? That is *entirely* the wrong question. It's why you haven't solved the problem yet. Look at the *radius server* debug output. It's the one sending the Session-Timeout. You should be able to figure out where the session-timeout is coming from. Where is Session-Timeout getting this information? Why is it only doing it on some accounts and not others? Look at the debug output. Honestly. We say this DAILY on this list. There is no excuse for refusing to do that. Alan, take a deep breath. Of course I've looked at the debug output. Note my opening sentence, ol' pardner. ;) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
Bill Isaacs wrote:
Ok so the question then is: where the hell is radclient getting the
notion that the account has 2366393 seconds left?
From the RADIUS server. This isn't magic. radclient doesn't invent
attributes in reply packets. It receives them from the RADIUS server.
Alan, take a deep breath. Of course I've looked at the debug output.
Note my opening sentence, ol' pardner. ;)
Well... your question about where does radclient get that value from
is entirely missing the point. It gets it from the RADIUS server. I've
said this. I have no idea how to convince you it's true.
And the *only* way to debug the RADIUS server is to look at the debug
output.
And no, your original message did *not* say you had run the server in
debugging mode. There's only a reference to creating an account for
debugging purposes. There's no radiusd -X output.
My frustration here is that the documentation and my messages cannot
possibly be any more clear. Yet you're wandering around doing
everything *but* what the documentation says, and then wondering why I'm
getting annoyed.
Run the server in debugging mode. Really. Do it. I mean it.
If you want to track down the issue to a specific module, update the
config to do:
update reply {
Reply-Message += A %{reply:Session-Timeout}
}
Cut paste that through various pieces of authorize, post-auth, etc.
Change the A to B, C, etc. You should see 10-20 Reply-Messages
in the Access-Accept. Each with a value for Session-Timeout. That lets
you track *what* the value is, and *where* in the config the value is
coming from.
Then once you know it's a particular module, you can figure out how to
fix that module.
Right now, you're staring at the radclient output, wondering why the
server isn't working. That's a mistake.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
On 02/08/2013 09:50 AM, Alan DeKok wrote:
Bill Isaacs wrote:
Ok so the question then is: where the hell is radclient getting the
notion that the account has 2366393 seconds left?
From the RADIUS server. This isn't magic. radclient doesn't invent
attributes in reply packets. It receives them from the RADIUS server.
Well... your question about where does radclient get that value from
is entirely missing the point. It gets it from the RADIUS server. I've
said this. I have no idea how to convince you it's true.
Alan, you're so much more fun when you're not being myopic. lol Of
course it's getting the answer from the radius server. You really think
I don't know that?
And the *only* way to debug the RADIUS server is to look at the debug
output.
And no, your original message did *not* say you had run the server in
debugging mode. There's only a reference to creating an account for
debugging purposes. There's no radiusd -X output.
You're quite right Alan, it didn't. NOR did I say that it did. To
paraphrase you, You're staring at the first sentence, wondering where
the debug output is. That's a mistake. :D
What I DID say was I'm researching this anomaly myself in all the
documentation, but thought it would also be helpful /both to me and to
others/ to post the problem here. (emphasis added).
What I implied in the ensuing message was that it would be posted here
once I tracked the message down, but that posting it and the solution
in nice digestible pieces for those not familiar at all with radius
would be helpful to them. I suspect if you went to decaf and quit
asking 'why' others don't just do what should be done, you would have
understood that.
Take a deep breath. Read between the lines, and realize that if others
understood radius the way you do, you'd be out of a job (at least on the
board here). I'm trying to make this fun, and be worthwhile as a
thread. So caaalm down. ok? I'll post the debug output along with
what it reveals as soon as I've worked it all out thoroughly. Trust me. :)
... why I'm
getting annoyed.
See decaf above.
If you want to track down the issue to a specific module, update the
config to do:
update reply {
Reply-Message += A %{reply:Session-Timeout}
}
Cut paste that through various pieces of authorize, post-auth, etc.
Change the A to B, C, etc. You should see 10-20 Reply-Messages
in the Access-Accept. Each with a value for Session-Timeout. That lets
you track *what* the value is, and *where* in the config the value is
coming from.
Then once you know it's a particular module, you can figure out how to
fix that module.
Now *there* is a wholly useful piece of information. Bravo! Sooner or
later, we'll clear out enough of the rants to expose goodies, no? :D
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
Bill Isaacs wrote: Alan, you're so much more fun when you're not being myopic. lol Of course it's getting the answer from the radius server. You really think I don't know that? I can only read what you write. You asked *twice* why radclient had that Session-Timeout. The second time, after I told you to look at the server. You then said you HAD mentioned you looked at the server output, when your messages made no such reference. I'm asking you to communicate clearly and honestly. If you can't do that, then you won't solve the problem. What I DID say was I'm researching this anomaly myself in all the documentation, but thought it would also be helpful /both to me and to others/ to post the problem here. (emphasis added). (a) looking at radclient, and (b) looking at the config, and NOT looking at the debug output. There are messages every day saying POST THE DEBUG OUTPUT. You didn't do that. You have failed the basic netiquette we ask for here. And then to top it off, get condescending to me when I point this out. What I implied in the ensuing message was that it would be posted here once I tracked the message down, You've failed to understand the need for the debug output. It is nearly everything you need to (a) debug, and (b) solve the problem. You don't post it here after you've come up with a solution. You post it here so that people with a clue can read it, and help you. but that posting it and the solution in nice digestible pieces for those not familiar at all with radius would be helpful to them. Nonsense. Again, you make it clear you don't understand. What is helpful is a *solution*. You posted a problem. You posted the wrong information about the problem. You are suggesting that people use the wrong *method* to track the problem down. You're wasting everyone's time. You're misleading future people, who will find your post, and potentially go down the wrong path. I suspect if you went to decaf and quit asking 'why' others don't just do what should be done, you would have understood that. I think you're being condescending and rude. Stop it. Take a deep breath. Read between the lines, and realize that if others understood radius the way you do, you'd be out of a job (at least on the board here). It doesn't take a rocket scientist to read the documentation, and post the debug output as suggested in the FAQ, man page, web pages, and daily on this list. You didn't do that. I really don't care why. The entire reason I'm an expert is that I'm willing to learn from others. I read the documentation, and I follow instructions. It's not hard. You don't do that. I'm trying to make this fun, and be worthwhile as a thread. So caaalm down. ok? I'll post the debug output along with what it reveals as soon as I've worked it all out thoroughly. Trust me. :) That is completely the wrong approach. You are misleading everyone else by suggesting that method. Stop it. Now *there* is a wholly useful piece of information. Bravo! Sooner or later, we'll clear out enough of the rants to expose goodies, no? :D I figured that it was hopeless to get you to follow the existing documentation. So maybe if I spoon-fed it to you in pieces you might think about it, and follow instructions. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
Again Alan, read between the lines. I've been scanning these emails
from this group for about year through google searches.
What I've learned from this mailing list is that you routinely castigate
people who ask questions on here. That's rude. Your tone is arrogant.
And that's rude.
Yes, I'm being condescending but it's in order to point out your
rudeness -- hopefully in an entertaining way. You're apparently a
hopeless case where that's concerned.
What it seems to me that this thread needs is a set of discussions that
don't include a staple diet of questioner-castigation, as you've done
here to me. OF course I expected it, even counted on it, to make the
point I'm making here. No one is being led down the wrong path. You
just need to lighten up and be a little less arrogant. A little nicer.
A human being.
And the whole thing sailed right over your arrogant head. Read this
exchange, and I rest my case right there.
I'm trying to make this fun, and be worthwhile as a
thread. So caaalm down. ok? I'll post the debug output along with
what it reveals as soon as I've worked it all out thoroughly. Trust me. :)
That is completely the wrong approach. You are misleading everyone
else by suggesting that method.
Stop it.
Now *there* is a wholly useful piece of information. Bravo! Sooner or
later, we'll clear out enough of the rants to expose goodies, no? :D
I figured that it was hopeless to get you to follow the existing
documentation. So maybe if I spoon-fed it to you in pieces you might
think about it, and follow instructions.
By the way Alan, I didn't need that spoon fed to me. I'm drawing out
information for the benefit of others and frankly, just seeing if you
have anything in your repertoire that doesn't include trying to belittle
people who are asking for help. Jury is still out on that one, but
wearing a frown as they deliberate. :)
Now for the useful stuff.
Here is the telling part of the freeradius -X output that I ran earlier
this morning and printed out to use as a reference in my inquiries:
[accessperiod] expand: %{sql:SELECT
IF(COUNT(radacctid=1),(UNIX_TIMESTAMP() -
IFNULL(UNIX_TIMESTAMP(AcctStartTime),0)),0) FROM radacct WHERE UserName
= 'cgitest' AND AcctSessionTime = 1 ORDER BY AcctStartTime LIMIT 1} -
231238
rlm_sqlcounter: Check item is greater than query result
rlm_sqlcounter: Authorized user cgitest, check_item=2592000, counter=231238
rlm_sqlcounter: Sent Reply-Item for user cgitest, Type=*Session-Timeout,
value=2360762*
++[accessperiod] returns ok
So, there's something fishy with the rlm_sqlcounter module. Looks like
the place to start.
Stay tuned, film at 11.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
Bill Isaacs wrote:
Again Alan, read between the lines. I've been scanning these emails
from this group for about year through google searches.
What I've learned from this mailing list is that you routinely castigate
people who ask questions on here. That's rude. Your tone is arrogant.
And that's rude.
Yes, I'm being condescending but it's in order to point out your
rudeness -- hopefully in an entertaining way. You're apparently a
hopeless case where that's concerned.
What it seems to me that this thread needs is a set of discussions that
don't include a staple diet of questioner-castigation, as you've done
here to me. OF course I expected it, even counted on it, to make the
point I'm making here. No one is being led down the wrong path. You
just need to lighten up and be a little less arrogant. A little nicer.
A human being.
And the whole thing sailed right over your arrogant head. Read this
exchange, and I rest my case right there.
I'm trying to make this fun, and be worthwhile as a
thread. So caaalm down. ok? I'll post the debug output along with
what it reveals as soon as I've worked it all out thoroughly. Trust me. :)
That is completely the wrong approach. You are misleading everyone
else by suggesting that method.
Stop it.
Now *there* is a wholly useful piece of information. Bravo! Sooner or
later, we'll clear out enough of the rants to expose goodies, no? :D
I figured that it was hopeless to get you to follow the existing
documentation. So maybe if I spoon-fed it to you in pieces you might
think about it, and follow instructions.
By the way Alan, I didn't need that spoon fed to me. I'm drawing out
information for the benefit of others and frankly, just seeing if you
have anything in your repertoire that doesn't include trying to belittle
people who are asking for help. Jury is still out on that one, but
wearing a frown as they deliberate. :)
Now for the useful stuff.
Here is the telling part of the freeradius -X output that I ran earlier
this morning and printed out to use as a reference in my inquiries:
[accessperiod] expand: %{sql:SELECT
IF(COUNT(radacctid=1),(UNIX_TIMESTAMP() -
IFNULL(UNIX_TIMESTAMP(AcctStartTime),0)),0) FROM radacct WHERE UserName
= 'cgitest' AND AcctSessionTime = 1 ORDER BY AcctStartTime LIMIT 1} -
231238
rlm_sqlcounter: Check item is greater than query result
rlm_sqlcounter: Authorized user cgitest, check_item=2592000, counter=231238
rlm_sqlcounter: Sent Reply-Item for user cgitest, Type=*Session-Timeout,
value=2360762*
++[accessperiod] returns ok
So, there's something fishy with the rlm_sqlcounter module. Looks like
the place to start.
Stay tuned, film at 11.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
Bill Isaacs wrote:
Here is the telling part of the freeradius -X output that I ran earlier
this morning and printed out to use as a reference in my inquiries:
[accessperiod] expand: %{sql:SELECT
IF(COUNT(radacctid=1),(UNIX_TIMESTAMP() -
IFNULL(UNIX_TIMESTAMP(AcctStartTime),0)),0) FROM radacct WHERE UserName
= 'cgitest' AND AcctSessionTime = 1 ORDER BY AcctStartTime LIMIT 1} -
231238
rlm_sqlcounter: Check item is greater than query result
rlm_sqlcounter: Authorized user cgitest, check_item=2592000, counter=231238
rlm_sqlcounter: Sent Reply-Item for user cgitest, Type=*Session-Timeout,
value=2360762*
++[accessperiod] returns ok
So, there's something fishy with the rlm_sqlcounter module.
All of this nonsense could have been prevented if you had posted this
in your first message. The debug output is clear:
1) it runs a query:
SELECT IF(COUNT(radacctid=1),(UNIX_TIMESTAMP() -
IFNULL(UNIX_TIMESTAMP(AcctStartTime),0)),0) FROM radacct WHERE UserName
= 'cgitest' AND AcctSessionTime = 1 ORDER BY AcctStartTime LIMIT 1
2) the query returns 231238
You can verify this by running the query manually. That's why it's
printed out in debugging mode.
3) 2592000 - 231238 = 2360762
This is maybe grade 5 math.
4) sqlcounter returns 2370762.
FreeRADIUS is working correctly.
5) Instead of following instructions, you wasted everyones time by
ignoring the documentation, and then arguing about it
6) you still blame FreeRADIUS, *despite* the pretty clear debug output
above. It doesn't take a RADIUS expert to figure it out.
7) Despite your poor attitude, I'm *still* trying to help you
8) If you respond by blaming me or putting me down, you will be
unsubscribed and banned from this list.
If you keep your messages technical, there's no problem. If you read
the documentation, there's no problem. If you follow instructions,
there's no problem.
The entire problem is you refusing to follow instructions, and then
arguing about it. You have this weird idea that I'm being rude for
telling you to FOLLOW THE DOCUMENTATION.
The only problem here is you. Fix your attitude, or you will be
unsubscribed and banned. There are hundreds of people a month who post
questions and get answers without any problem. Choose to be one of them.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session-Timeout anomalies
Alan, Being a moderator does NOT give you moral license to treat people like children. You're a rude man. Please ban me. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
