Status counters

[Anders Holm]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20081221/37f2b17e/attachment.html>