svn commit: samba r11804 - in branches/SAMBA_4_0/source: librpc/rpc torture/rpc

[tridge at samba.org]

Volker,

I've spent a couple of hours trying to work out why the async rpc code
is failing so many tests, but haven't managed it yet. It seems to work
for some of the ncacn_np tests, but none of the ncalrpc or
ncacn_ip_tcp tests. Most of 'make quicktest' fails :-(

Would you be able to revert the async rpc auth changes until they are
in a bit better shape? The async binds on ncalrpc and ncacn_ip_tcp are
more complex than async bind on ncacn_np as it has to cope with the
epm mapping stage.

more detailed comments ....

The base dcerpc_bind_{send,recv} code looks OK to me, although I'm not
sure that 
   p->conn->transport.recv_data = bind_request_recv
is the best approach. It's probably no worse than what we had before,
but it doesn't allow you to do a bind while a previous async rpc
request is still pending. Perhaps it would be better use a common
recv_data handler between normal requests and binds, then look at the
pkt.ptype of the reply to see if it is a bind reply. If it is then
call the bind handler, otherwise the normal handler. I don't know if
windows servers allow you to do a bind while a async request is
pending, but it still seems like the wrong approach to change the
receive handler here. 

There also seems to be a problem with handling of the auth flags
(c->flags). I can make some of the ncacn_ip_tcp tests pass by forcing
'connect', 'sign' or 'seal' in the binding string. Trying a
DCERPC_AUTH_LEVEL_NONE bind fails as gensec (correctly) rejects
it. What I don't understand is what is is about your changes that
breaks this, and also why a connection with a username/password isn't
automatically getting the DCERPC_CONNECT flag set. I suspect the logic
that handled this must have been lost in one of your recent patches
but I haven't found the culprit yet.

I also noticed another (old) bug while looking at this. When we make a
dcerpc connection on ncacn_ip_tcp we do name resolution twice, first
when we do the epm connection then again when we do the main
connection. The problem with this is that the two name resolutions
could easily give two different results, and the two hosts might use
different epm mappings for the service. We need to carry over the name
resolution from the epm connection to the main connection. Maybe the
easiest solution would be for the epm code to fill in a
binding->host_address field, and to skip name resolution when that is
filled in.

Cheers, Tridge