s3: Fix bug 8334, do not fork the echo handler for smb2
authorVolker Lendecke <vl@samba.org>
Wed, 31 Aug 2011 13:06:35 +0000 (15:06 +0200)
committerVolker Lendecke <vlendec@samba.org>
Wed, 31 Aug 2011 15:58:48 +0000 (17:58 +0200)
If a smb1 negprot negotiated smb2 we forked the echo responder. This will
eventually lead to a panic from

[2011/08/30 10:33:29.212578,  0, pid=3846917] smbd/smb2_server.c:243(smbd_smb2_request_create)
  Invalid SMB packet: first request: 0x0009

because from the echo responder we always read using the normal smb1 protocol
handling routine. If that is a bit down the smb2 stream, we get a non-negprot
packet and panic.

BTW, the echo responder is not required for smb2 anyway, Microsoft confirmed
that it probes the server liveness using TCP keepalives and not smb2 echo
requests.

Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Wed Aug 31 17:58:48 CEST 2011 on sn-devel-104

source3/smbd/negprot.c

index a58744281c6021f7f11c07117be6a182fa2c6533..236b4d66926723c5147cb092c7e7a097fa10331a 100644 (file)
@@ -743,7 +743,8 @@ void reply_negprot(struct smb_request *req)
 
        TALLOC_FREE(cliprotos);
 
-       if (lp_async_smb_echo_handler() && !fork_echo_handler(sconn)) {
+       if (lp_async_smb_echo_handler() && (get_Protocol() < PROTOCOL_SMB2) &&
+           !fork_echo_handler(sconn)) {
                exit_server("Failed to fork echo handler");
        }