Norman Elton wrote:
Well, I understand how the alive/zombie/dead process SHOULD work, but I'm having trouble lining it up with what we're seeing. We're proxying to a windows NPS box. Here's the proxy config:
Part of the issue is that the timers on the proxy are independent of the timers on the client. The timers on the proxy fire ONLY when it receives packets from the client. So if the client doesn't retransmit, or if it retransmits on an unusual pattern, proxying becomes more difficult.
Now, for whatever reason, the Windows box decides to discard some requests. Unfortunately, the error reporting is pretty weak ("discarding invalid request"). Our Windows guys are digging into this. It seems to be client specific, we suspect something with our recently changed certificate.
I don't see how. Normal RADIUS doesn't use certificates. And if your home server *randomly* discards requests, then your priority should be to fix that. No amount of poking FreeRADIUS will make the home server magically work. No amount of poking FreeRADIUS will work around the fact that the home server is broken.
FreeRadius is dropping into zombie state, which is expected given that the home server is dropping requests. But our logs and packet captures indicate that the home server is never dropping the "ping_user" status checks that FR is using to determine the home server state. But, our FreeRadius logs indicate that the home_server is being flagged 'dead' immediately upon becoming zombie:
Check which version of the server you're running. Old versions sometimes had issues with zombie timers. See doc/ChangeLog for details.
Why is the server going into zombie state at 20:32:26 and immediately becoming dead at 20:32:27? Shouldn't it wait for the entire zombie_period before dropping dead?
Yes. Alan DeKok.