<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alan DeKok wrote:
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">Anders Holm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Heh. I sure did. Though, I'm thinking slightly differently I suppose..
"How can something be accepted which has not been requested?".
</pre>
</blockquote>
<pre wrap=""><!---->
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:
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-ietf-radext-status-server-03">http://tools.ietf.org/html/draft-ietf-radext-status-server-03</a>
</pre>
</blockquote>
Ah, the missing piece emerges. This is probably what I was missing.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">
Which was written by... me.
</pre>
</blockquote>
So, what you're saying is that I am talking to the right guy about
this. Good.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Are you being deliberately obtuse? Or just deliberately difficult?
</pre>
</blockquote>
Neither. I'm deliberately trying to understand how it all works. The
draft you linked above may or may not do so.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
Ah. 3 simple rules that weren't spelled out anywhere in the
documentation you mean?<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">
Why? Because Status-Server packets aren't Access-Request packets!
</pre>
</blockquote>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">They're spelled differently! And *pronounced* differently!
</pre>
</blockquote>
Oh, I do know how to read and write. Talking works too.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<blockquote type="cite">
<pre wrap="">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" | \"
</pre>
</blockquote>
<pre wrap=""><!---->
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".
</pre>
</blockquote>
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.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">
And nothing is being authenticated. No user, no machine, nothing.
Nothing is asking for access.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">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?
</pre>
<pre wrap=""><!---->
This is a fascinating discusion in how a simple example can be twisted
into something unrecognizable.
</pre>
</blockquote>
I find it a fascinating example of how misunderstandings can go way out
of order instead of trying to be rectified.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
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?<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> There is only one Status-Server packet. I don't know what you mean by
"Status-*"
</pre>
</blockquote>
<pre wrap="">If one separates the Requests versus Accepts and Rejects, I'd see 3 ..
If one follows the set examples for other counters anyway.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
In all honesty, you could have posted them right away then. People
aren't mind readers.<br>
<blockquote cite="mid:494DE5E5.9020005@deployingradius.com" type="cite">
<blockquote type="cite">
<pre wrap="">Sure. In your own scenario you're considering several clients. On disk
isn't good enough either. Losing a disk also means losing data.
</pre>
</blockquote>
<pre wrap=""><!---->
You only have one disk? You must be terribly poor.
</pre>
</blockquote>
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.<br>
<br>
//anders<br>
</body>
</html>