Greetings, While testing a setup that uses inner tunnel proxying I was noticing that there were spurious failures if the setup was stress tested. I managed to eliminate back-end latency as a possible cause by testing instead to a simple auth against rlm_passwd (with NTLM crypts.) I also tried with both servers running recent 3.0 repo code, so it's a problem that has likely been there at least from 2.1.10. After a long dig through the debugs, finally I noticed from a packet dump that packets with 0x00 vectors were hitting the wire, and when IDs were recycled that of course results in false "duplicates" (as well as the other crypto-related issues with that.) The packets with the 0x00 vectors were the inner-tunneled packets emitted from the proxying server. If I understand things right, these packets are generated by the EAP modules allocating a fake request, which is passed back through as if the server were handling the inner tunnel itself, and then when the proxy codepath is taken, this "fake" packet is then recycled as the outgoing request to the home server. Looking through the source we have this warning in request_alloc_fake src/main/utils.c: /* * This isn't STRICTLY required, as the fake request MUST NEVER * be put into the request list. However, it's still reasonable * practice. */ ...however this seems to be just what is happening. In fact, if above that I change: diff --git a/src/main/util.c b/src/main/util.c index 94ee443..e6a1a26 100644 --- a/src/main/util.c +++ b/src/main/util.c @@ -437,7 +437,7 @@ REQUEST *request_alloc_fake(REQUEST *request) */ fake->server = request->server; - fake->packet = rad_alloc(0); + fake->packet = rad_alloc(1); if (!fake->packet) { request_free(&fake); return NULL; ...then the setup passes stress testing just fine. Trouble is I'm not sure if there are ramifications to doing that...