Age | Commit message (Collapse) | Author | Files | Lines |
|
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Mon Sep 12 19:12:21 CEST 2011 on sn-devel-104
|
|
metze
|
|
metze
|
|
metze
|
|
metze
|
|
This moves the SMB1 specific stuff to cli_smb_req_create(),
instead of having it in the core dispatching code.
metze
|
|
This will allow handling of SMB2 in future.
metze
|
|
metze
|
|
metze
|
|
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Fri Aug 12 12:36:03 CEST 2011 on sn-devel-104
|
|
in cli_smb_received()
Callers of tevent_req_done() (or similar functions) have to return directly.
Otherwise the callback could invalidate the current stack state,
which is likely to trigger segfaults.
If there was only one pending request and we just got the response
for that one, we can use tevent_req_done() directly.
Otherwise there're more pending requests and we need to call
cli_state_receive_next() or we got the response for chained requests.
Both means that we have to use tevent_req_defer_callback().
metze
|
|
metze
|
|
It's up to the caller to notify the current request,
but we have to notify all other pending requests if
we're not able to read the next response from the server.
metze
|
|
metze
|
|
metze
|
|
for chained requests
metze
|
|
metze
|
|
If we got a problem on the connection we need to notify every
pending request. But we need to make use of tevent_req_defer_callback()
before tevent_req_nterror(), otherwise the callback, triggered
by tevent_req_nterror(), could invalidate the state of current caller,
which will likely cause segfaults.
metze
|
|
In cli_echo with more than one response we ended up with more than one read_smb
request. One from the call to cli_smb_req_set_pending called from
cli_smb_received. The other one from cli_smb_received itself. I don't really
see another way to deal with this than to hold the read_smb request in the
cli_state.
Metze, please check!
Volker
|
|
metze
|
|
metze
|
|
metze
|
|
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Fri Jul 22 09:53:59 CEST 2011 on sn-devel-104
|
|
metze
|
|
cli_state_[g|s]et_tid()
metze
|
|
metze
|
|
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Wed Jul 13 01:19:51 CEST 2011 on sn-devel-104
|
|
We keep the raw error in cli->raw_status now, until we fixed all
caller to get the NTSTATUS from the function calls.
metze
|
|
This fixes a few Coverity errors
|
|
This will be used for correct signing in [nt]trans[2][s] requests.
metze
|
|
If the mid was set explicitly, it means the request expects more than
one reply, so leave it in the pending array.
metze
|
|
directly
metze
|
|
requests
metze
|
|
We are here only if we have more than one num_pending
Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Mon Jun 6 18:21:17 CEST 2011 on sn-devel-104
|
|
Several places want "milliseconds from current time", and several were
simply doing "msec * 1000" which can (and does in one place) result in
a usec value over 1 a million.
Using a helper to do this is safer and more readable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
|
|
|
|
|
|
|
I have a test failure on my 32-bit Ubuntu system, in that
samba3.smbtorture_s3.plain(s3dc).LOCK9 immediately times out (rather than
waiting 5 seconds for the child).
Debugging revealed this code: timeout is in ms and is set to > 1000 in
various places. The code dates from 2002, and other perturbations didn't
reveal why it breaks now, but fix it anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Autobuild-User: Rusty Russell <rusty@rustcorp.com.au>
Autobuild-Date: Tue May 10 12:09:07 CEST 2011 on sn-devel-104
|
|
Guenther
|
|
|
|
Guenther
Autobuild-User: Günther Deschner <gd@samba.org>
Autobuild-Date: Fri Apr 29 14:00:30 CEST 2011 on sn-devel-104
|
|
We might find a better name for it and merge other namequery related things as
well here...
Guenther
|
|
Guenther
|
|
This does not do the redirects, but I think that might be obsolete anyway
|
|
When winbind sees a signing error on the smb connection to a DC (for whatever
reason, our bug, network glitch, etc) it should recover properly. The "old"
code in clientgen.c just closed the socket in this case. This is the right
thing to do, this connection is spoiled anyway. The new, async code did not do
this so far, which led to the code in winbindd_cm.c not detect that we need to
reconnect.
|
|
Guenther
|
|
DOS error codes were being lost with the conversion to async
libsmbclient. If we're passing around NTSTATUS internally,
let's just convert it when we get it.
DOS ACCESS_DENIED on nautilus was not prompting for other credentials,
because it was not being mapped.
|
|
The caller doesn't want a timeout.
Jeremy.
|
|
I've tried to solve this just within cli_smb_recv(), but I could not find a way
to sanely determine when we are receiving the last entry in the chain just from
looking at the blob. This solves it in an a bit more brutal way...
|