On 03/29/2012 10:52 AM, Jari Takkala wrote:
> Hello,
>
> I came across the same TCP RST issue as reported in
> http://tracker.nagios.org/view.php?id=305. I've attached a patch for
> nrpe.c, and also check_nrpe.c as pointed out by dnsmichi.
>
> The problem is that when we call SSL_shutdown() only once, the server
> sends an SSL shutdown message to the client. The client then responds
> with it's own SSL shutdown message, and this ends up in the server's
> socket receive buffer. However, since we never consume this message,
> the kernel will send a RST to the client when the server process
> exits. This pollutes our firewall logs and makes it harder to detect
> more serious TCP errors in our monitoring.
>
> The solution is to call SSL_shutdown() at least twice, and up to 4
> times to be safe (usually SSL_shutdown() will return 1 after two
> calls). There's a good explanation of this behaviour in the links I
> provided within the bug report. I won't take up too much space
> explaining it here.
>
> Please apply the attached patch. Thanks!
>
While the reason and the spirit behind the patch is sensible, the
code itself is horrible.
* Write a wrapper to shutdown the connection so you don't have to
duplicate the code everywhere. close_connection() would be a good
name for it, and it should handle the #ifdef HAVE_SSL stuff as well
so it can be removed from (most) of the application logic.
* Add a short sleep-timer between calls, or poll() the underlying
socket for inbound data so the other node has time to send a
response. I imagine your patch will work horribly on links from
Europe to China, for instance, because latency will be too high.
Resubmit the patch with the above changes and it'll have a much
higher chance of being accepted.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]