svn commit: samba r6219 - in branches/SAMBA_4_0/source: librpc/rpc ntvfs/posix

[Richard Sharpe]

On Thu, 7 Apr 2005, Andrew Tridgell wrote:

> Richard,
>
>  > My guess is that the absence of Extended Security Exchanges in the NegProt
>  > response capabilities word is triggering one less bit in the negotiate
>  > flags.
>
> I think that is highly unlikely, but please do test the theory.
>
> I think it is more likely that lack of NetrServerAuthenticate3 or
> something else at the RPC level is what triggers the behaviour. You
> could test this by blocking NetrServerAuthenticate3 using either a
> hacked up sockspy, or using a modification to the rpc proxy backend in
> Samba4.

Well, the trace I have shows that both the NetrServerAuthenticate3 and
the NetrServerAuthenticate2 used negotiate flags of 0x6007BFFF.

However, that still doesn't tell us why it chose that set of flags ...
doing further investigation.

>  > However, the problem seems to be that in dcerpc_pipe_connect_ncacn_np we
>  > throw away all information about what the server told us it was capable
>  > of.
>
> no, we don't throw away information like that, but we do hide it deep
> in the structures as it is almost always wrong to use that information
> at this level.
>
> If you really truly think it is the right way to do this, and have
> good evidence that this is the case, then the capabilities are
> available in the smb_private structure in dcerpc_smb.c, in
>
>   private->tree->session->transport->negotiate.capabilities
>
> but please don't just take a guess at this and use that variable. I
> will be quite surprised if it is the correct approach.

Yeah, I found that, although I would have to cast private to something
usable :-(

Regards
-----
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com