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.