Adam Bultman wrote:
After some work getting 2.1.9, and v2.1.x from the git repository up and running, I had to go back to 2.1.7-7, that is patched (hopefully, anyway!) for the "zombie" problem, via the patch you sent me. The 2.1.9 and 2.1.10 versions would die unexpectedly, right around the time the "Info: ... ... adding new socket command file /var/run/radiusd/radiusd.sock " would scroll through the debug. I couldn't figure it out for the life of me, and strace didn't give me too much - it'd just segfault right around that time.
Don't use strace to track down SEGVs. It won't help. See doc/bugs for instructions on tracking down SEGVs. Those instructions work.
Yup. They can upgrade to a (cough) real radius server. :)
Turns out, they were a bit stand-offish. They didn't like their radius servers being implicated in the mix. "It's working for 30+ clients, so we have no plans to upgrade".
Exactly... "no one else has noticed a problem, so we're not going to fix it." I guess they don't fix leaks in the roof of their house. When it doesn't rain, it doesn't leak. When it rains, it's too wet to fix the leak.
One thing I also noticed was that it it doesn't look like freeradius is giving it very many tries on a packet before marking the system down.
FreeRADIUS doesn't retry packets when proxying. The *NAS* retries packets. FreeRADIUS retransmits only when it receives a packet from the NAS.
At least, that's the way it appears. I don't know how to use wireshark filters enough to find unacked packets, so I have to do that before I'll be able to piece that together.
Why use wireshark? The server has a debug mode...
It is also noteworthy that upon pingscanning their network, I found two IP addresses that are up - and I'm getting packet loss to them. Between 4 and 7 percent, which while not a ton, might be enough to cause a problem if I'm relaying thousands of packets an hour.
Yup.
Thanks for the help, Alan. I appreciate it.
It's what I do. Alan DeKok.