Pre-release of Version 2.1.8

[Alan DeKok]

Bjørn Mork wrote:
> Yes, now it continues to answer both authentication and accounting
> requests, but it still stops proxying after a while (where "a while"
> might be something like 20+ hours and 1+ million auth requests - I have
> no indication that these values are fixed).  

  Look for the message:

Failed creating new proxy socket: server is too busy and home servers
appear to be down

  It *should* continue to proxy after that, but it *won't* create new
outgoing sockets.  And it *won't* proxy any more requests until the
current requests have timed out.

  If the upstream servers really are that bad, I suggest configuring
local detail files, as in raddb/sites-available/robust-proxy-accounting.
   This should make the server log packets locally, and *not* track them
in memory (which appears to be the problem).

> There are a number of servers marked "alive", but these are all servers
> which have been revived after the fixed period.  When used, they will be
> marked dead/zombie again.

  Configure "status_check".  Really.  Get the upstream servers to permit
status-checks for a "test" user.  It will make your network *much* more
robust.

  And why are the upstream servers dying so consistently?  You're really
in a corner case where you're testing FreeRADIUS in situations where the
network Just Doesn't Work.  The suggestions above should help work
around most of those issues.

> But I will test that now, starting with the stable branch from
> git.freeradius.org, commit d7b4f003477644978f3fefa694305dce9b5dc8bf,
> which was the last point where things seemed to work

  If that works, we could do a "git bisect" to find the issue.  There
are only 26 commits since them, and many of those don't have code
changes.  It shouldn't be too hard to track down the offending commit.

  Alan DeKok.