Memory usage in 3.0

[Alan DeKok]

  The other benefit of this code is that it should now be possible (with some more code changes) to detect EAP packets which traverse a different proxy path.

  i.e. packets go: supplicant -> AP -> RADIUS client -> proxy 1 -> home server

  3-4 packets later, proxy 1 fails.  We now have packets going:

	supplicant -> AP -> RADIUS client -> proxy 2 -> home server

  in the *middle* of an EAP conversation.  Right now, the server just says "unknown EAP state", and the auth fails.

  With a bit more work, we could find the State from the original packet, and echo back the original reply to proxy2, instead of to proxy1.  That should help a bit with proxy fail-over.

  Comments?  Stones?

On Sep 18, 2015, at 11:10 AM, Alan DeKok <aland at deployingradius.com> wrote:

>  We moved to per-request memory pools in 3.0.8 or so.  The benefit is that the server should spend less time doing allocations.   The down side seems to be that the server is using more memory.  A lot more memory.   In some cases, double what it used before.  So for 3.0.10 we've decreased the size of the pools, which means that the memory goes back to something reasonable.
> 
>  A related problem is multi-packet EAP sessions.  A typical PEAP session can take 10-15 round trips.  Due to the possibility of packets being lost, the server caches request and responses for 5 seconds.  That makes sense for PAP.  It doesn't make sense for PEAP.
> 
>  Why?  When PEAP request packet N+1 is received from the client, we *know* that the client has received PEAP reply packet N.  So we can clean that reply packet up immediately, instead of sitting on it for another 5 seconds.  The result is that the server should only be sitting on *one* live packet, instead of 1 live one, and 10 old ones.
> 
>  The attached patch implements that checking.  The new behaviour is automatic, and can't be turned off.  I'd appreciate it if people could test the patch, and see if it (a) doesn't break the server, and (b) helps with memory pressure, and (c) doesn't impact performance too much.
> 
>  The patch is against v3.0.x from today (5333d5d179da).  I'm wary of putting the patch into 3.0, but it may be a good candidate for 3.1.
> 
>  Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html