Support for TCP

[jake-scott]

It would be useful for pam_radius to support TCP. In particular, using UDP it is difficult for pam_radius to know if a server is down or just taking a while to respond and that makes it difficult to tune timeouts to support failover properly.

In my use case, the RADIUS server can take a long time to respond when it prompts the user over a separate channel like a mobile push request. There doesn 't seem to be a sensible response it can send back to the client to tell it that the auth is underway. So the client has to decide when to give up and move on to another server. When it does that there will be another push sent to the user.

Using TCP would help here as the client could be configured to move on to other servers if it can't connect and have a separate request timeout once it has connected to a server.

I would be willing to work on this and provide a patch if people think this is a useful feature.

[alandekok]

RADIUS doesn't support a "still working on it" packet notification, so that can't be done.

If you need to support both fail-over and long timeouts, then TCP is a reasonable choice. I think the patches should be small. Please send them over and I'll take a look.

[jake-scott]

I had a go at adding this support, sorry it took so long - see : #112

This was a little more involved than I had expected. I ended up refactoring the socket initialization code away from the config reading stage and into the talk_radius stage because you can't re-use TCP sockets like you can with UDP.

I opted for a global use_tcp option rather than making this a per server option as that sounded hard with the existing config file format. I modified the per server timeout value to accept two comma separated numbers - the read timeout (equivalent to the existing timeout) and a second connect timeout used only for TCP.

Let me know what you think, happy to make any changes.

Thanks -- Jake