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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
