s4-drs: Issues with DsReplicaGetInfo() reply message

Erick Nascimento erick.nogueira.nascimento at gmail.com
Thu Dec 3 13:13:52 MST 2009


Hi Tridge,

I'm having some issues with the reply of the DsReplicaGetInfo() request.
I implemented the function kccdrs_replica_get_info() which handles
this drs rpc call. In that, I construct the reply (filling the 'out'
field of req struct).

I've done some tests with a win2k8 machine, running "repadmin
/showrepl mylinuxbox", which is supposed to return the Inbound
Neighbours (repsFrom) of the mylinuxbox DC. The result should be just
the w2k8 DC, but it doesn't show any Inbound Neighbours on the result.
Am I constructing the reply in a wrong way or is there something more
that needs to be done ?

One doubt:
What is the meaning of the field "req.out.status"? Is it the status
that goes inside the reply message, so that the DC that receives that
message checks the status value inside it? That value is of type
WERROR, but the return type of kccdrs_replica_get_info() must be
NTSTATUS. Is the return value of kccdrs_replica_get_info() (which
returns to kcc_service.c:kccsrv_replica_get_info()) used only inside
samba, or not (it is used in some way inside the reply message) ?

And finally:
As I construct the reply, I have to copy fields from one struct to
another. For that, I'm not doing a "deep" copy (allocate space for the
pointer fields, and copy one-by-one), just a shallow one. Of course,
sometimes I need to allocate some struct here and there, and put it on
req->out.
My question is: I can't free the memory allocated by
kccdrs_replica_get_info() (mem_ctx) *inside* the function, because
req->out has pointers that uses that memory, and it is used *outside*
the function. Is this a problem ? If so, there is a right way to solve
this? Is the memory freed after the message is sent?

My code is on the following repo, on the last commit:
http://repo.or.cz/w/Samba/nascimento.git/blob/HEAD:/source4/dsdb/kcc/kcc_drs_replica_info.c

Best Regards,
Erick Nogueira do Nascimento


More information about the samba-technical mailing list