RE: Configure SQL to timeout requests rather than rejecting if no connections available

21 Jan 2015

      ...
...
After a few days of operating this and recreating my "crushing load"
situation with the log files open, it looks like when the virtual server does not
respond, the "master" server is still kicking a reject -- the log entry is:
Auth: Login incorrect (Home Server failed to respond): *snipped client
info*
So, do I need to do the same syntax for the "suffix" module in my master
virtual server?
No.  The "suffix" module just marks the request as "it should be proxied".
The suffix module doesn't actually do the proxying.
The issue is that you don't want to respond to the *client*.  You *do* want
the virtual server to respond to the proxy.
As always, run the server in debugging mode to see what's going on.  It will
quickly become clear what's going on.  And, *where* you need to make
changes.
In your existing configuration, you can probably just change the proxying, to
add:
post-proxy {
  ...
  Post-Proxy-Type Fail {
      do_not_respond
  }
...
}
And the proxy won't respond to the client.  But I'd have to see the full
debug log to be sure.
Alan DeKok.
So, "in your existing configuration" means what I have with the virtual server not responding on an SQL "fail"?  Or to revert that change and then add that post-proxy handling?

My server configuration currently (with the virtual server not responding on SQL "fail") is:
---
server platreg {
	authorize {
		mikrotik_realm
		suffix
	}

	preacct {
		mikrotik_realm
		suffix
	}
}

server platreg_hotspot {
  authorize {
    update request {
      SQL-Reply-Table := 'ml_hotspot_freeradius_service_radreply'
    }
    platreg {
      fail = 1
    }
    if ( fail ) {
      do_not_respond
    }
  }

  authenticate {
    Auth-Type CHAP {
      chap
    }
  }

  preacct {
    preprocess
    acct_unique
    suffix
    files
  }

  accounting {
    detail
    unix
    radutmp
    platreg
    exec
    attr_filter.accounting_response
  }

  post-auth {
    exec
    Post-Auth-Type REJECT {
      # log failed authentications in SQL, too.
      platreg
      attr_filter.access_reject
    }
  }	
}
---

So, basically, the mikrotik_realm module looks at the realm name that came in from the client (which might be requesting hotspot.metalink.net or dhcp.metalink.net) and update the username to username@realm.  Suffix then proxies it off to the virtual server named platreg_<realm>

"platreg" is the name of my sql module.

I can't easily run the live servers in debug mode -- they're under fairly heavy volume and it's hard to get useful information from them.  I have fairly high request logging turned up at the moment, and I can try to set up my debug environment with a test case that could replicate the issue if necessary.

Thank you,

Noah Engelberth
System Administration
MetaLINK Technologies
nengelberth@team-meta.net
419-990-0342