Re: Status counters
Anders Holm wrote: Ah, the missing piece emerges. This is probably what I was missing. My frustration is that I explained how it works. Rather than believing that explanation, you started arguing about the rationale behind the explanation. That wasn't necessary. Are you being deliberately obtuse? Or just deliberately difficult? Neither. I'm deliberately trying to understand how it all works. The draft you linked above may or may not do so. It was explained. Status-Server packets get Access-Accept responses. Access-Request counters don't get incremented for Status-Server packets. You can believe the explanations, or you can argue about them. Ah. 3 simple rules that weren't spelled out anywhere in the documentation you mean? I had explained them in my earlier email. The one you argued with. No, nothing is asking for access. Something is asking for status. This is why I spelled out the 3 Status counters I did. sigh There are no 3 status counters. This has been explained. Starting with a Status-Request, not an Access-Request. There is no Status-Request packet. Why are you inventing it? I my mind, the result of that is either a Status-Accept or Status-Reject. There is no Status-Accept packet or Status-Reject packet. Why are you inventing them? Now, I still haven't had a chance to read that draft, I'm just saying how I'm thinking about it. Your thinking is wrong. When I say Status-Server packet... I mean Status-Server. Not Status-Request. When I say Access-Accept packet, I mean Access-Accept, not Status-Accept. This is really the fundamental part of the miscommunication. I mean what I say. I write what I mean. Yet when I do that, you interpret it as meaning something else. Why? This is a fascinating discusion in how a simple example can be twisted into something unrecognizable. I find it a fascinating example of how misunderstandings can go way out of order instead of trying to be rectified. Just... stop. I've given the same explanation multiple times. I've tried to rectify your misunderstandings. You have (even in this message) refused to understand that the response to a Status-Server is an Access-Accept. Not a Status-Accept. Not a Status-Reject. Even when I gave the 3 simple rules, one of which is: c) The response to Status-Server is Access-Accept You *still* talk about the response to a Status-Request being a Status-Accept. Uh... WTF? Did you not understand the line (c) above? And you accusing *me* of not trying to rectify a misunderstanding ? Believe me, I'm trying. Multiple times. Yet you are *consistently* ignoring my answers, and talking about Status-Request, and Status-Accept. If you're not going to read my response, I don't understand why you're asking questions. I'm about to read it. So, what you're saying there is someone else than the author I should ask if I don't understand it? See how easy things get misunderstood? I'm saying that I obviously lack the skills to explain it to you. Witness your responses to my message: I say Status-Server, you read Status-Request. I say Access-Accept, you read Status-Accept. I don't know how to fix that problem on my end. If this sounds mean... please explain to me how it's nice to read: c) The response to Status-Server is Access-Accept and then to respond with: Starting with a Status-Request... the result of that is either a Status-Accept or Status-Reject. ? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Alan, all I'm trying to do is talk things over. You take that as arguing. I have understood what you have stated. I'm just trying to tell you, it isn't as obvious always as you might think it is. Sure, for you it is easy, as you've even written the RFCs. Not everyone has the background knowledge you do, which means they'll ask questions about things. That is all I have done here. I did also tell you, I've not had a chance to read the draft yet. Things may still clear up for me. So, give me that chance to read things and get the understanding you have. There surely is no need to get into a huff about things, is there? //anders Alan DeKok wrote: Anders Holm wrote: Ah, the missing piece emerges. This is probably what I was missing. My frustration is that I explained how it works. Rather than believing that explanation, you started arguing about the rationale behind the explanation. That wasn't necessary. Are you being deliberately obtuse? Or just deliberately difficult? Neither. I'm deliberately trying to understand how it all works. The draft you linked above may or may not do so. It was explained. Status-Server packets get Access-Accept responses. Access-Request counters don't get incremented for Status-Server packets. You can believe the explanations, or you can argue about them. Ah. 3 simple rules that weren't spelled out anywhere in the documentation you mean? I had explained them in my earlier email. The one you argued with. No, nothing is asking for access. Something is asking for status. This is why I spelled out the 3 Status counters I did. sigh There are no 3 status counters. This has been explained. Starting with a Status-Request, not an Access-Request. There is no Status-Request packet. Why are you inventing it? I my mind, the result of that is either a Status-Accept or Status-Reject. There is no Status-Accept packet or Status-Reject packet. Why are you inventing them? Now, I still haven't had a chance to read that draft, I'm just saying how I'm thinking about it. Your thinking is wrong. When I say Status-Server packet... I mean Status-Server. Not Status-Request. When I say Access-Accept packet, I mean Access-Accept, not Status-Accept. This is really the fundamental part of the miscommunication. I mean what I say. I write what I mean. Yet when I do that, you interpret it as meaning something else. Why? This is a fascinating discusion in how a simple example can be twisted into something unrecognizable. I find it a fascinating example of how misunderstandings can go way out of order instead of trying to be rectified. Just... stop. I've given the same explanation multiple times. I've tried to rectify your misunderstandings. You have (even in this message) refused to understand that the response to a Status-Server is an Access-Accept. Not a Status-Accept. Not a Status-Reject. Even when I gave the 3 simple rules, one of which is: c) The response to Status-Server is Access-Accept You *still* talk about the response to a Status-Request being a Status-Accept. Uh... WTF? Did you not understand the line (c) above? And you accusing *me* of not trying to rectify a misunderstanding ? Believe me, I'm trying. Multiple times. Yet you are *consistently* ignoring my answers, and talking about Status-Request, and Status-Accept. If you're not going to read my response, I don't understand why you're asking questions. I'm about to read it. So, what you're saying there is someone else than the author I should ask if I don't understand it? See how easy things get misunderstood? I'm saying that I obviously lack the skills to explain it to you. Witness your responses to my message: I say Status-Server, you read Status-Request. I say Access-Accept, you read Status-Accept. I don't know how to fix that problem on my end. If this sounds mean... please explain to me how it's nice to read: c) The response to Status-Server is Access-Accept and then to respond with: Starting with a Status-Request... the result of that is either a Status-Accept or Status-Reject. ? Alan DeKok. - 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: Status counters
Anders Holm wrote: all I'm trying to do is talk things over. You take that as arguing. Q: How does this work? A: It works like this. Q: I think it works like that. A: No, I said like this. In detail. Q: But I really think it works like that! A: Stop it. Q: Stop what? sigh I have understood what you have stated. I'm just trying to tell you, it isn't as obvious always as you might think it is. Sure, for you it is easy, as you've even written the RFCs. It's easy. I gave you 3 simple rules. You said you understood them. And then you got them wrong. Not everyone has the background knowledge you do, which means they'll ask questions about things. That is all I have done here. I did also tell you, I've not had a chance to read the draft yet. Things may still clear up for me. So, give me that chance to read things and get the understanding you have. I gave you multiple chances to read my messages. You couldn't even reproduce Status-Server or Access-Accept accurately. You instead used Status-Request and Status-Accept. I mean geez... that's a simple cut paste. What's the problem? There surely is no need to get into a huff about things, is there? Yes, there is. Answer the following question: If this sounds mean... please explain to me how it's nice to read: c) The response to Status-Server is Access-Accept and then to respond with: Starting with a Status-Request... the result of that is either a Status-Accept or Status-Reject. ? If you can't (or won't) answer it, then you are admitting that the miscommunication isn't on *my* end. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Anders Holm wrote: Looking a tad at the counters and how they get incremented I see the following: Sending Access-Accept of id 20 to 127.0.0.1 port 32772 FreeRADIUS-Total-Access-Requests = 0 FreeRADIUS-Total-Access-Accepts = 36 FreeRADIUS-Total-Access-Rejects = 0 FreeRADIUS-Total-Access-Challenges = 0 FreeRADIUS-Total-Auth-Responses = 36 This is on a test server, which currently is only getting requests for status. Shouldn't the Access-Requests also be incremented? No. The counter tracks Access-Requests, not Status-Server packets. I mean, if the Access-Accept is incremented, we must have had a request to being with. No. The response to a Status-Server is an Access-Accept. Also, using these counters for monitoring, it would be nice to see deltas from the previous Status request. Though, if I would go ahead and clear the counters (haven't even checked if it is possible tbh) I might have requests arriving between my last Status request packet and my clearing the counter, meaning my metrics would be incorrect. Would it be trivial to add some form of delta-since-last-status-request, or is it preferred to keep that in an external script? It would be extremely difficult. *Who* asked for those statistics last? Is the last statistics item tracked by client IP? Client port? Anything else...? Just trying to figure out which would be the best route, and what others think of the idea. Might be useful for others here, so ... If you need deltas, track them yourself in the client app. It's the only way to get them right. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Alan DeKok wrote: Anders Holm wrote: Looking a tad at the counters and how they get incremented I see the following: Sending Access-Accept of id 20 to 127.0.0.1 port 32772 FreeRADIUS-Total-Access-Requests = 0 FreeRADIUS-Total-Access-Accepts = 36 FreeRADIUS-Total-Access-Rejects = 0 FreeRADIUS-Total-Access-Challenges = 0 FreeRADIUS-Total-Auth-Responses = 36 This is on a test server, which currently is only getting requests for status. Shouldn't the Access-Requests also be incremented? No. The counter tracks Access-Requests, not Status-Server packets. I mean, if the Access-Accept is incremented, we must have had a request to being with. No. The response to a Status-Server is an Access-Accept. So, for Access-Requests we ignore Status-Server packets, but Status-Server packets do increment Access-Accept? Would there be a counter for Status-Requests, so I could correlate the figures so I can figure out what is what? Would there be an idea to have separate counters just for the Status-* type counters? Might be one handy way to handle that, as that'd separate those type of stats from each other as well as giving higher resolution. Also, using these counters for monitoring, it would be nice to see deltas from the previous Status request. Though, if I would go ahead and clear the counters (haven't even checked if it is possible tbh) I might have requests arriving between my last Status request packet and my clearing the counter, meaning my metrics would be incorrect. Would it be trivial to add some form of delta-since-last-status-request, or is it preferred to keep that in an external script? It would be extremely difficult. *Who* asked for those statistics last? Is the last statistics item tracked by client IP? Client port? Anything else...? Indeed. Conundrum to say the least. I'll look at various alternatives, but marshalling through a central location and letting the marshal keeping track of previous and current numbers and returning the delta is probably the safest way to handle that. Just trying to figure out which would be the best route, and what others think of the idea. Might be useful for others here, so ... If you need deltas, track them yourself in the client app. It's the only way to get them right. Mmm.. Even then there'd be potential race conditions, data loss etc. I'd be using this data to gather metrics, and then in turn have alarms based on those metrics (levelling and thresholds). Ensuring the base data is correct then is of importance. OR at least understanding what the base data is telling us is of importance I should say .. ;) //anders - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Anders Holm wrote: So, for Access-Requests we ignore Status-Server packets, but Status-Server packets do increment Access-Accept? Perhaps you didn't see my message or read the names of the counters. One counter counts Access-Requests, and another one counts Access-Accepts. There is no ignore of Status-Server packets. The reason for incrementing Access-Accepts has been explained. Would there be a counter for Status-Requests, so I could correlate the figures so I can figure out what is what? Sure. Send a patch. Would there be an idea to have separate counters just for the Status-* type counters? Might be one handy way to handle that, as that'd separate those type of stats from each other as well as giving higher resolution. There is only one Status-Server packet. I don't know what you mean by Status-*. If you need deltas, track them yourself in the client app. It's the only way to get them right. Mmm.. Even then there'd be potential race conditions, data loss etc. Huh? You have one client app querying the server and keeping track of deltas. Other client apps query it. And data loss can be prevented by keeping track of counters on disk, too. I'd be using this data to gather metrics, and then in turn have alarms based on those metrics (levelling and thresholds). Ensuring the base data is correct then is of importance. OR at least understanding what the base data is telling us is of importance I should say .. ;) Sure. Track it, store it, no problem. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Alan DeKok wrote: Anders Holm wrote: So, for Access-Requests we ignore Status-Server packets, but Status-Server packets do increment Access-Accept? Perhaps you didn't see my message or read the names of the counters. One counter counts Access-Requests, and another one counts Access-Accepts. There is no ignore of Status-Server packets. The reason for incrementing Access-Accepts has been explained. Heh. I sure did. Though, I'm thinking slightly differently I suppose.. How can something be accepted which has not been requested?. And I understand why the Accepts increment. I just don't understand why the Requests aren't, as that how I'd look at a query to get the Status, a Request which specifically is an Access-Request to get Status-Server data returned. At least, that is my view. Considering I'm using exactly what the example from the Wiki tells me, there is an Authentication, so logically, I'm asking for Access. # echo Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 1 | \ So, Access-Accepts I got no problem with. That stacks up. Requests and Rejects is what I'm curious about. If my shared secret is wrong for example, doesn't that get counted as an Access-Reject, or doesn't it get counted at all? Would there be a counter for Status-Requests, so I could correlate the figures so I can figure out what is what? Sure. Send a patch. Sure. Would there be an idea to have separate counters just for the Status-* type counters? Might be one handy way to handle that, as that'd separate those type of stats from each other as well as giving higher resolution. There is only one Status-Server packet. I don't know what you mean by Status-*. If one separates the Requests versus Accepts and Rejects, I'd see 3 .. If one follows the set examples for other counters anyway. If you need deltas, track them yourself in the client app. It's the only way to get them right. Mmm.. Even then there'd be potential race conditions, data loss etc. Huh? You have one client app querying the server and keeping track of deltas. Other client apps query it. And data loss can be prevented by keeping track of counters on disk, too Sure. In your own scenario you're considering several clients. On disk isn't good enough either. Losing a disk also means losing data. There's a lot of different variables to consider, as I'm building a highly available and not to mention reliable platform. Can be achieved with either multiple clients checking Status, or a hot-cold setup, or.. or.. or.. There's multiple choices, with varying degrees of reliability and completely different sets of failure scenarios. I'd be using this data to gather metrics, and then in turn have alarms based on those metrics (levelling and thresholds). Ensuring the base data is correct then is of importance. OR at least understanding what the base data is telling us is of importance I should say .. ;) Sure. Track it, store it, no problem. I have a feeling that's the better approach of them all .. Store the Status values in a replicated database, and have the monitoring clients have some decent smarts. Needs some pondering I think. //anders - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Anders Holm wrote: Heh. I sure did. Though, I'm thinking slightly differently I suppose.. How can something be accepted which has not been requested?. That is the definition of how Status-Server works. This definition goes back to 1996 in a number of RADIUS servers. It is now being standardized: http://tools.ietf.org/html/draft-ietf-radext-status-server-03 Which was written by... me. And I understand why the Accepts increment. I just don't understand why the Requests aren't, as that how I'd look at a query to get the Status, a Request which specifically is an Access-Request to get Status-Server data returned. At least, that is my view. Are you being deliberately obtuse? Or just deliberately difficult? a) There is a counter for Access-Requests b) There is a counter for Access-Accepts c) The response to Status-Server is Access-Accept That's how it works. 3 simple rules that anyone should be able to understand. There is no counter for Status-Server, and the Access-Request counter is not incremented when a Status-Server packet is received. Why? Because Status-Server packets aren't Access-Request packets! They're spelled differently! And *pronounced* differently! Considering I'm using exactly what the example from the Wiki tells me, there is an Authentication, so logically, I'm asking for Access. # echo Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 1 | \ Now you are being *deliberately* misleading. The next line that you *conveniently* didn't quote is: radclient localhost:18120 status adminsecret See the status word? The radclient documentation says that this means send Status-Server. And nothing is being authenticated. No user, no machine, nothing. Nothing is asking for access. So, Access-Accepts I got no problem with. That stacks up. Requests and Rejects is what I'm curious about. If my shared secret is wrong for example, doesn't that get counted as an Access-Reject, or doesn't it get counted at all? This is a fascinating discusion in how a simple example can be twisted into something unrecognizable. The RADIUS *packet* is being signed. No RADIUS *users* are being authenticated. And the response to a Status-Server is *never* Access-Reject. Go read my draft. If you don't understand it, read it again. If you still don't understand it, ask someone *else* about it. There is only one Status-Server packet. I don't know what you mean by Status-* If one separates the Requests versus Accepts and Rejects, I'd see 3 .. If one follows the set examples for other counters anyway. Nonsense. This confusion happens only because you fail to comprehend the 3 simple rules I posted above. Instead, you are working valiently to come up with a tortured explanation based on a near-total misunderstanding. Sure. In your own scenario you're considering several clients. On disk isn't good enough either. Losing a disk also means losing data. You only have one disk? You must be terribly poor. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Of course, I'm silly enough to expect others know what versions I'm running .. *doh* This is with FreeRADIUS 2.1.1 compiled from source. //anders 2008/12/19 Anders Holm anders.h...@sysadmin.ie Hi folks. Looking a tad at the counters and how they get incremented I see the following: Sending Access-Accept of id 20 to 127.0.0.1 port 32772 FreeRADIUS-Total-Access-Requests = 0 FreeRADIUS-Total-Access-Accepts = 36 FreeRADIUS-Total-Access-Rejects = 0 FreeRADIUS-Total-Access-Challenges = 0 FreeRADIUS-Total-Auth-Responses = 36 This is on a test server, which currently is only getting requests for status. Shouldn't the Access-Requests also be incremented? I mean, if the Access-Accept is incremented, we must have had a request to being with. Also, using these counters for monitoring, it would be nice to see deltas from the previous Status request. Though, if I would go ahead and clear the counters (haven't even checked if it is possible tbh) I might have requests arriving between my last Status request packet and my clearing the counter, meaning my metrics would be incorrect. Would it be trivial to add some form of delta-since-last-status-request, or is it preferred to keep that in an external script? Just trying to figure out which would be the best route, and what others think of the idea. Might be useful for others here, so ... //anders - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
