[Nagiosplug-help] Problem with TCP-Sessions via check_smtp or check_ssh

[Holger Weiss]

* sp2148421 <sp2148421 at web.de> [2007-08-04 09:36]:
> But in my opinion the source problem of the (tcp-based)-checks is,
> that they didn't wait for [FIN,ACK] from Server-Site after sending
> themself a [FIN,ACK].

No.  The sequence would normally look like:

Packet 1) client > server: [FIN]   => client done with writing
Packet 2) server > client: [ACK]   => packet (1) acknowledged
Packet 3) server > client: [FIN]   => server done with writing
Packet 4) client > server: [ACK]   => packet (3) acknowledged

The packets (2) and (3) would usually be combined into a single packet.
However, the problem is that the plugin close(2)s the socket for reading
before the server was done with sending data, which leads to:

Packet 1) client > server: [FIN]   => client done with writing
Packet 2) server > client: [ACK]   => packet (1) acknowledged
Packet 3) server > client: <data>  => the response to the SMTP QUIT
Packet 4) client > server: [RST]   => the server's data is refused

Again, the packets (2) and (3) will usually be combined into a single
packet.  Here, closing the socket causes a TCP FIN, which tells the
server that no more data will be sent from the client.  This FIN is
ACK'd just fine by the server.  However, the server will still try
(once) to send its data (as the TCP FIN doesn't imply that the client
stopped reading from the socket).  The client will reject this data with
a TCP RST.  Due to this RST, the server won't send a TCP FIN at all.

As an example, here are the final packets of a check_smtp session
without my patch:

1) nagios.35545 > mail.smtp: P 15:21(6) ack 141 win 257
2) nagios.35545 > mail.smtp: F 21:21(0) ack 141 win 257
3) mail.smtp > nagios.35545: P 141:192(51) ack 22 win 256
4) nagios.35545 > mail.smtp: R 686166743:686166743(0) win 0

Packet (1) includes the SMTP QUIT command sent by the plugin (and a
piggy-backed ACK for the data it received before).  It sent 6 bytes of
data ("QUIT\r\n"), which happens to be byte 15 up to but not including
byte 21 of the stream.  Packet (2) is the TCP FIN caused by the plugin
closing the socket immediately after sending the QUIT (and it includes
the same ACK as before, but that's irrelevant).  The server now sends
the SMTP response to the client's QUIT command.  This comes in via
packet (3), which also includes a piggy-backed ACK for both the data (up
to but not including byte 21) and the TCP FIN (hence, "ack 22") sent by
the client.  However, the client stopped reading from the socket, so
packet (3) will be rejected with an RST in packet (4).

With my patch, the connection shutdown looks like this:

1) nagios.35612 > mail.smtp: P 15:21(6) ack 141 win 257
2) mail.smtp > nagios.35612: P 141:192(51) ack 21 win 256
3) nagios.35612 > mail.smtp: F 21:21(0) ack 192 win 257
4) mail.smtp > nagios.35612: F 192:192(0) ack 22 win 256
5) nagios.35612 > mail.smtp: . ack 193 win 257

Packet (1) includes the SMTP QUIT command, as before.  Now, the plugin
waits for the response instead of closing its socket, hence packet (1)
isn't followed by a TCP FIN.  Packet (2) includes the server's SMTP
response to the QUIT and a piggy-backed ACK of it ("ack 21").  The
plugin now reads that response and _then_ closes its socket, causing
packet (3), which sends the TCP FIN and includes a piggy-backed ACK for
the received data.  The server ACK's the FIN ("ack 22") and sends its
own FIN in packet (4), which is then ACK'd by the plugin in packet (5).

<de>Alle Klarheiten beseitigt?</de> [*] :-)

Holger

[*] "Everything perfectly unclear, now?"

-- 
PGP fingerprint:  F1F0 9071 8084 A426 DD59  9839 59D3 F3A1 B8B5 D3DE