radsecproxy.git, branch radsecproxy-1.6.9

Ready for radsecproxy-1.6.9.

2017-08-02T13:53:51+00:00

Don't follow the NULL pointer, not even in debug printouts.

2017-08-02T11:09:43+00:00

Bug reported by Leonhard Knauff.

Closes RADSECPROXY-68.

Use a listen(2) backlog of 128.

2017-08-02T11:04:47+00:00

There's a chance that incoming (legitimate) connections arrive faster
than what it takes to spawn a new thread and get back to
listen(). Therefore we should ask the stack to queue at least one
entry, i.e. use a backlog value of at least 1. There's arguable also a
chance of more than two concurrent incoming connections, which would
make a case for a backlog value greater than one.

A reasonable high value seems to be 128, which also is what SOMAXCONN
is on many unix systems. In the choice between 1 and 128, an argument
against the higher value is that it may mask the potential problem of
spending a long time serving incoming connections.

Being reasonably confident that radsecproxy is efficient when it comes
to serving incoming connections, by handing them off to a newly
spawned thread, I think that 128 is a fine choice.

Closes RADSECPROXY-72.

Update ChangeLog with -77.

2017-08-02T08:08:47+00:00

Merge branch 'RADSECPROXY-77' into maint-1.6

2017-08-02T08:06:54+00:00

Update ChangeLog.

2017-08-01T16:27:24+00:00

Move allocation of memory, making error case simpler.

2017-08-01T16:25:37+00:00

Make warning about failing IPV6_V6ONLY info level.

2017-08-01T16:25:37+00:00

We might have a bug where bindtoaddr() tries to set V6ONLY on IPv4
sockets. Until that's been resolved, don't alarm users on debug level
'warning'.

Verify return code from fcntl calls.

2017-08-01T16:25:36+00:00

Have connectnonblocking() warn and fail if setting O_NONBLOCK fails.
Have it warn if restoring of flags fail.

coverity: 1449515

Cleanup varargs in error case too.

2017-08-01T16:25:36+00:00

coverity: 1449517