Hi Alan,
I've just tried to use raddebug to capture the debug, but I might have unearthed another problem. Once raddebug times out after 60 second it kills radiusd.
Does the server *die*? The debug log doesn't show that.
The debug I attached was from capture of a terminal, I didn't use raddebug in the end. Before that I ran radiusd, then raddebug; after a minute my test auths were failing and discovered the radius process had stopped. I've just done it again, raddebug start & stop times are below, and below that is snippet from radius.log [root@server raddb]# date; raddebug; date Tue Nov 12 20:33:08 GMT 2013 Tue Nov 12 20:34:09 GMT 2013 Tue Nov 12 20:32:59 2013 : Info: Ready to process requests. Tue Nov 12 20:33:08 2013 : Info: ... adding new socket control address port 0 Tue Nov 12 20:33:08 2013 : Info: ... closing socket control address port 0 Tue Nov 12 20:33:08 2013 : Info: ... adding new socket control address port 0 Tue Nov 12 20:33:08 2013 : Info: ... closing socket control address port 0 Tue Nov 12 20:33:09 2013 : Info: ... adding new socket control address port 0 Tue Nov 12 20:33:09 2013 : Info: ... closing socket control address port 0 Tue Nov 12 20:33:09 2013 : Info: ... adding new socket control address port 0 Tue Nov 12 20:33:09 2013 : Info: ... closing socket control address port 0 Tue Nov 12 20:34:09 2013 : Info: ... adding new socket control address port 0 Tue Nov 12 20:34:09 2013 : Info: talloc: double free error - first free may be at src/main/listen.c:3218 Tue Nov 12 20:34:09 2013 : Info: Bad talloc magic value - double free
This line is then repeated over 1 million times ...
Tue Nov 12 13:13:36 2013 : Debug: (162) Waiting for more responses from the home server
That's not supposed to happen. What is the value of "response_window" for that home server? If it's zero, then that's the problem.
response_window isn't set for the three eduroam homeservers. Is it defaulted to zero if not set? Thanks, Jezz.