Bug 11225 - multiplexed RPC connections are not handled by DCERPC server
Summary: multiplexed RPC connections are not handled by DCERPC server
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DCE-RPCs and pipes (show other bugs)
Version: unspecified
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Blocks: 11226 11236
  Show dependency treegraph
Reported: 2015-04-20 10:25 UTC by Julien Kerihuel (mail address dead)
Modified: 2020-12-11 07:04 UTC (History)
5 users (show)

See Also:
jelmer: review+

patch to add support for multiplexed connections (2.81 KB, patch)
2015-04-20 10:25 UTC, Julien Kerihuel (mail address dead)
no flags Details
patch for v4-1 series (3.05 KB, patch)
2015-04-20 14:35 UTC, Julien Kerihuel (mail address dead)
jra: review+
git-am fix for 4.2.next. (2.88 KB, patch)
2015-04-21 21:09 UTC, Jeremy Allison
jra: review? (jelmer)

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Kerihuel (mail address dead) 2015-04-20 10:25:21 UTC
Created attachment 10967 [details]
patch to add support for multiplexed connections

Samba 4 was not handling multiplexed connections properly in dcerpc server. The implementation, committed in master in caaf89e899c2a3926fb9e54d1c86f1a9cd5d7618 is adding a flag similar to DCESRV_CALL_STATE_FLAG_ASYNC to dcesrv_call_state_flags to define whether a service supports this behavior or not.

Microsoft Exchange is implementing a DCERPC endpoint server
called async_emsmdb with a single asynchronous call named
EcDoAyncWaitEx. When Outlook sends a EcDoAsyncWaitEx request, the server
does not reply  unless there is either a notification for Outlook to
process or the timeout of 5 minutes is reached. Without this patch,
Microsoft Outlook clients block and do not move further with any of the
existing connections from DCERPC altered context unless the call to
EcDoAsyncWaitEx actually returns. With this patch, Outlook operates
properly and as expected.

Scope of the patch:
I have identified that implementing this multiplexed connection behavior
was both required when:

    1. initializing a new connection, hence dcesrv_bind

    2. when altering an existing context, hence dcesrv_alter. However,
    in this specific case we don't have existing state_flags on the
    connection. It is therefore necessary to save  and retrieving the
    flags from the existing context to decide whether or not the
    DCERPC_PFC_FLAG_CONC_MPX should be applied to the state_flags of the
    current connection.
Comment 1 Julien Kerihuel (mail address dead) 2015-04-20 14:35:18 UTC
Created attachment 10972 [details]
patch for v4-1 series
Comment 2 Jeremy Allison 2015-04-21 21:04:49 UTC
Comment on attachment 10972 [details]
patch for v4-1 series

LGTM. 4.2.x version also needed - I will attach.
Comment 3 Jeremy Allison 2015-04-21 21:09:58 UTC
Created attachment 10973 [details]
git-am fix for 4.2.next.

This is a direct cherry-pick from master.
Comment 4 Jeremy Allison 2015-04-21 21:11:10 UTC
Comment on attachment 10973 [details]
git-am fix for 4.2.next.

Jelmer please +1 for 4.2.next.
Comment 5 Jeremy Allison 2015-04-22 03:33:53 UTC
Re-assigning to Karolin for inclusion in 4.2.next, 4.1.next.

Karolin, Jelmer +1'ed the bug itself rather than the attachment, but it means the same thing :-).

Comment 6 Julien Kerihuel (mail address dead) 2015-04-24 10:33:09 UTC
A regression/crash introduced by this patch has been identified when an unknown dcerpc endpoint is queried in dcesrv_alter. 

I have created a bug entry and attached a fix to address this problem:

Comment 7 Karolin Seeger 2015-04-27 19:56:57 UTC
Pushed to autobuild-v4-[1|2]-test.
Comment 8 Karolin Seeger 2015-05-04 18:47:14 UTC
Pushed to both branches.
Closing out bug report.