Ryan Melendez wrote:
I wish I knew. One thing I specifically mention is that the two radius servers are bound to two different virtual interfaces with unique IPs.
That shouldn't matter...
So I'm now wondering if there is something fundamentally wrong with how the kernel treats two udp sockets:
1)listening on the same port 2)bound to two different IPs, one of which is a VIF on the same physical interface 3)in two entirely different processes
I'm inclined to say hell no, but stranger things have happened.
It's certainly possible that it's not a well tested portion of the kernel. In any case, set O_NONBLOCK on the sockets, and the problem should be fixed.
Hmm... even 1.1.x can have one process listen on multiple interfaces. Why not try that? I need to replicate acct data. I have radrelay replicating the data from the detail file of one sever to the other server bound to a virtual interface. This is the only way I found I could replicate the data while still getting the failover/unique proxy/timeout requirements. The second radius server only gets acct packets via radrelay originally sent to the first radius server.
Hmm.... 2.0 may handle that a lot better.
I haven't figured out what port 1814 is actually used for. Is there anything I could do to disable the "proxy port" on one or both of the servers? What would I loose?
The ability to send packets to other servers. 1814 is used when FreeRADIUS is acting as a RADIUS client (i.e. proxy). Alan DeKok.