As the encryption is stream based there's no reason

oplock breaks can't be encrypted. If we have multiple
contexts I should probably attach them to the connection
struct, but for now use the global context number.
Jeremy.
(This used to be commit 5b4b335ed0)

source3/smbd/oplock.c

@@ -252,11 +252,13 @@ static char *new_break_smb_message(TALLOC_CTX *mem_ctx,
 	}
 
 	memset(result,'\0',smb_size);
-	/* We use cli_set_message here as this is an
+	if (!srv_encryption_on()) {
-	 * asynchronous message that doesn't belong in
+		cli_set_message(result,8,0,true);
-	 * the stream.
+	} else {
-	 */
+		char inbuf[8];
-	cli_set_message(result,8,0,True);
+		smb_set_enclen(inbuf,4,srv_enc_ctx());
+		srv_set_message(inbuf,result,8,0,true);
+	}
 	SCVAL(result,smb_com,SMBlockingX);
 	SSVAL(result,smb_tid,fsp->conn->cnum);
 	SSVAL(result,smb_pid,0xFFFF);

source3/smbd/seal.c

@@ -47,6 +47,15 @@ bool srv_encryption_on(void)
 	return false;
 }
 
+/******************************************************************************
+ Return global enc context - this must change if we ever do multiple contexts.
+******************************************************************************/
+
+uint16 srv_enc_ctx(void)
+{
+	return srv_trans_enc_ctx->es->enc_ctx_num;
+}
+
 /******************************************************************************
  Create an auth_ntlmssp_state and ensure pointer copy is correct.
 ******************************************************************************/