NRPE SSL_shutdown patch

Leo Baltus Leo.Baltus at omroep.nl
Fri Mar 30 09:28:05 CEST 2012


Op 29/03/2012 om 09:52:46 +0100, schreef Jari Takkala:
> 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.
> 

We observed the same problem and have been running with a patch for a
few weeks now, I was about to send a patch too :)

It is not releated to ssl as it also shows up on no-ssl nrpe instances.
The problem is with the closing of the sockets as you have identified.
Both nrpe and check_nrpe seem to close at almost the same time and this
is the root of the problem.

I will prepare my patch and send it to the list in a separate mail
together with an updated IPv6 patch I sent earlier.

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer at omroep.nl, 035-6773555                         \/

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure




More information about the Developers mailing list