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.