radiusd deadlock on recvfrom on port 1814

[Alan DeKok]

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.