prs_init and smb_io_* functions

Jean Francois Micouleau Jean-Francois.Micouleau at
Sun Nov 26 22:42:18 GMT 2000

On Sun, 26 Nov 2000, Mayers, Philip J wrote:

> Ugh, Samba's internals are *horrible*... ;o)

it's much more cleaner that it used to :-)

> Could someone give me a quick overview of the prs_* functions and the
> smb_io_* functions, and their intended usage pattern.

the prs_* functions are at a lower layer that the smb_io_* functions. The
prs_* functions are responsible to init/allocate mem, copy data in
prs_struct buffers.

The smb_io_* functions are at an higher level. They are using the basic
prs_* functions and check the endianess of the machine, if the data is

 The reason I ask is
> that I'm using the following code in the extended-security negotiation:


> Am I doing things right? The blob pointer is a pointer into the
> smb_buf(inbuf) of the SMB packet - provided I supply a False to the
> prs_give_memory call, that's OK, right?

yep, that's ok, why is blob a pointer to void ?

 The related question is I need to
> MARSHELL an challenge packet into the SMB outbuf - is it OK to do that,
> provided I give the right length for the memory. When I'm done, how do I get
> the *actual* length of the parsed-out data?

Yep, you need to initialise (english spelling) another prs_struct for
that. You don't need to know the size for that, the prs buffer will grow
as more memory is required. 

For the actual length you can call prs_offset(ps).

> Finally, how can I return NT status code 0xC0000016 - the "ERROR" macro
> seems to depend on the NT status code bit being set in the Flgs2 of the SMB
> outbuf, so I just set that flag, right?

Think so. I would need to read the code to be sure.


More information about the samba-technical mailing list