Samba defines 8 functions from the MS-SRVS protocol that [MS-SRVS] states are not to be used on the wire. Specifically, they are: 
NDR_SRVSVC_NETCHARDEVENUM (0x00)
NDR_SRVSVC_NETCHARDEVGETINFO (0x01)
NDR_SRVSVC_NETCHARDEVCONTROL (0x02)
NDR_SRVSVC_NETCHARDEVQENUM (0x03)
NDR_SRVSVC_NETCHARDEVQGETINFO (0x04)
NDR_SRVSVC_NETCHARDEVQSETINFO (0x05)
NDR_SRVSVC_NETCHARDEVQPURGE (0x06)
NDR_SRVSVC_NETCHARDEVQPURGESELF (0x07)
NDR_SRVSVC_NETCONNENUM (0x08)

The IDL in Appendix A in [MS-SRVS] states that opnums 0-8(inclusive) are not used on wire, that is, Windows will return NT_STATUS_INVALID_PARAMETER or other error code if they are used.

Samba implements and the RPC-SRVSVC suite tests these functions anyway.

Roughly, [MS-SRVS] provides an RPC based replacement for [MS-RAP], and [MS-RAP] doesn't have functions for remotely working with Character Devices (NetCharDevEnum, etc...).

Samba(at least Samba4.0.0alpha12-GIT-72cd5bc) doesn't implement these functions and instead returns WERR_NOT_SUPPORTED. So Samba should fail this suite too.

Further, its hard to see what use NetCharDevEnum, etc... would have over a network, other than being a security hole. 

Therefore, I believe the WSPP documentation ([MS-SRVS]) is correct in this case.


If Samba wants to extend [MS-SRVS] by implementing and using these functions when targeting another Samba host, thats certainly ok.

However, Windows doesn't support that extension of [MS-SRVS].

Samba, as in the RPC-SRVSVC test suite, or smbd, or smbclient, must not use opnums 0-8 on the srvsvc interface when targeting a Windows host.