Alan DeKok wrote:
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
Ah, the missing piece emerges. This is probably what I was missing.
Which was written by... me.
So, what you're saying is that I am talking to the right guy about this. Good.
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?
Neither. I'm deliberately trying to understand how it all works. The draft you linked above may or may not do so.
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.
Ah. 3 simple rules that weren't spelled out anywhere in the documentation you mean?
Why? Because Status-Server packets aren't Access-Request packets!
They're spelled differently! And *pronounced* differently!
Oh, I do know how to read and write. Talking works too.
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".
No, I'm deliberately trying to show how it looks to me. I actually missed copying the next line, not deliberately leaving it out. You're seeing things that are not there.
And nothing is being authenticated. No user, no machine, nothing. Nothing is asking for access.
No, nothing is asking for access. Something is asking for status. This is why I spelled out the 3 Status counters I did. Starting with a Status-Request, not an Access-Request. I my mind, the result of that is either a Status-Accept or Status-Reject. Now, I still haven't had a chance to read that draft, I'm just saying how I'm thinking about it.
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.
I find it a fascinating example of how misunderstandings can go way out of order instead of trying to be rectified.
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.
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?
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.
In all honesty, you could have posted them right away then. People aren't mind readers.
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.
Hardly. I just plan for the inevitable. Inevitably hardware fails. When it does, I have no intention of sitting there feeling sorry for my self that my data is gone. //anders