intermittent auth issue (proxy: request is no longer in proxy hash)

Alan DeKok aland at deployingradius.com
Fri Jul 4 02:39:11 CEST 2014


Chris Knipe wrote:
> I looked at the -default- proxy.conf, that comes with FR3.0.3 which is
> what I am using.  There isn't anything there in terms of request
> timeouts, just timeouts which controls when the proxy goes into a dead
> and/or zombie state - which is not what we are discussing here (again
> sorry if I missed it - a reference may thus be a good option). The
> proxy is never marked as dead, nor as a zombie, otherwise the natural
> thing for me WOULD HAVE been to look at and consider timeouts - that's
> why zombie / dead server configurations are there, isn't it?

  The proxy.conf file has a "response_window" configuration item.  It
controls how long a proxied request is marked "outstanding" before the
proxy marks it as failed.

> The client that sends the request, the FR server that does the
> proxing, as well as the FR server that receives the proxied request is
> under my control and neither one of them are timing out.

  The "not in proxy list" message indicates that (a) it's timing out, or
(b) there's a bug.

> Please try and be helpful. I would appreciate it.

  I can unsubscribe you from the list if you don't like my help.

>  I *DID* post the
> debug logs, both of a request that works, as well as a request that
> does not work.

  You posted PART of the debug log.  If you've been on the list for any
length of time, you will see this behavior as a REPEATED problem.
People post 3-4 lines, and expect some kind of magical solution.  They
then get cranky when they're told they need to read (or post) the FULL
debug output.

  i.e. what's happening now.

>  It is clear that for SOME reason, FR executes
> post_proxy in one request, and not in another.

  Saying that repeatedly is annoying.  That's another one of my pet
peeves.  People who ask questions, and say the same thing over and over
and over and over.

   We get it.  There's a problem.  Now stop complaining about the
problem, and work towards a solution.

>  The attributes
> received in both packets are the same.  This is NOT a configuration
> issue, nor a timeout issue IMHO.  If I knew why FR is behaving like
> this, I would have fixed it.  I am here however, to seek assistance to
> try and find out WHY this is happening.

  You really don't get it.

  We are TRYING to help you.  Your response is to wave your hands and
say THINGS ARE GOING WRONG.  Well... yes.  We're aware of that.

>>   That shouldn't happen.  Please try the v3.0.x branch from git.
> 
> But it *IS* happening - that's the whole point of why I am here asking
> 'experts' as to WHY it is happening.

  <sigh>  We're not miracle workers.  When you post ~10 lines of the
debug output and a description of what's going wrong, I can't magically
say "Oh yes, it's a bug in file X line Y".  Sometimes I can do that.
But in this case I can't.

  Now stop demanding a magical solution, and *cooperate*.

>  I will however try the latest
> code and see whether the issue persist.

  That's really the point here.

> I have since modified my rlm_perl application to use the authorize
> section to proxy requests to the parent radius server myself.  In
> other words, I am no longer using FR's proxy implementation, but
> rather do it myself using perl.  It's been running like that now for
> close to 12 hours, and I have not had *one* single Authentication
> error.  There is *something* in FR's proxy code causing this issue,
> and it's related to high amounts of "concurrent" requests for the same
> username.

  So... try the code from v3.0.x branch in git.

> I am sending the exact same packet via authorize, instead of
> the FR proxy modules, and it's working.  It is thus NOT a timeout
> issue, it is NOT related to attributes received / not received, but
> rather, related to SOMETHING that the proxy modules does / does not do
> when a response is received.

  No.  You are guessing as to how the server works.  Don't do that.

>  Again, as Phil said, it's more than
> likely too soon to call a bug, but it sure is leaning towards that and
> looking like it.

  I may be an idiot, but the server is *supposed* to proxy requests
properly.  If it doesn't that sure sounds like a bug.

> Let's first get some background.

  Most of that doesn't matter.

  i.e. your long description is looking at entirely the wrong thing.

  The packet contents don't matter.  Whether the client is an NNTP
server, NAS, PAM client, or magic pixies doesn't matter.  What the home
is running doesn't matter.  What the home server is doing doesn't matter.

> Now, THIS is where I think the issue is coming in.  The accept packet
> from the remote server, will *always* be identical.

  No.  That is NOT how RADIUS works.

>  The
> Configuration-Token returned will change over time, but for all
> initial 30 or 40 "simultaneous" authentication requests, the same
> Configuration-Token is returned.  The main FR server thus sees 30
> identical packets, to 30 different requests.

  No.  That is NOT how RADIUS works.

> What happens now, is that FR will take the 1st response it receives,
> and will push that through post_proxy.  The remaining responses for
> some reason goes directly to post_auth, instead of what should be,
> post_proxy.  The problem ONLY presents itself in requests sent to
> proxied servers, and it ONLY presents itself when there is a high
> amount of "concurrent" requests... Say, more than 10 within a very
> short period of time.  This is essentially what I tried to show by
> posting the radsecproxy log, together with the log from my perl
> module.

  No.  That is NOT how RADIUS works.

  Much of your time is spent on completely useless things.  Like going
down the wrong path, repeating the same things over and over, and
arguing with me.

  Stop it.  If you want to get the problem fixed, you need to work with
others.

  It may be a bug in v3.0.3.  But I don't see that when I do my tests.
If you try the v3.0.x branch from git, all known bugs are fixed.

  But if the v3.0.x branch has the same behavior, you need to provide
the FULL debug output.  And work from the assumption that we have a
little bit of a clue about how FreeRADIUS works.

  Alan DeKok.


More information about the Freeradius-Users mailing list