radiusd deadlock on recvfrom on port 1814

[Ryan Melendez]

On Fri, 2007-11-02 at 14:33 +0100, Alan DeKok wrote:
> Ryan Melendez wrote:
> > I'm not positive that select is lying about data being available. It
> > could be that there is data when select is called, but _something_ out
> > of line grabs it before recvfrom() can get to it.
> 
>   Like what?  There is nothing else listening on that IP address/port.
> The socket API makes sure of that.

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.
So both servers are running on the same physical interface.  My only
guess at this point is that something is going on with how virtual
interfaces work under the hood.  So something lower than the socket
API...

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.

> > Again, this only started happening when I began running two radiusd
> > processes on different interfaces on a multihomed system.  I also have
> > radrelay binding to one interface and replicating acct packets to the
> > other process.
> 
>   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.


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?


Thanks,
Ryan