Hi All,
The winreg_enumvalue digs out values perfectly fine from the tdb and
this is observed in the server side log.smbd. However on the rpc
client side no value is listed. More importantly it receives junk.
The problem perhaps lies with the idl.
Another thing I've observed while using the winreg_SetValue call - I
could pass an utf8 string to the api while it says it requires utf16
string.
Why this is important - when the registry db inits, some values which
are default registry values for certain keys go in as utf8. I wonder
if the winreg_enumvalue api requires the strings in the tdb to be
utf16 too ?
regards,
Chetan S

10/13/06, Chetan S <cshring (AT) gmail (DOT) comwrote:
Hi All,

The winreg_enumvalue digs out values perfectly fine from the tdb and
this is observed in the server side log.smbd. However on the rpc
client side no value is listed. More importantly it receives junk.

The problem perhaps lies with the idl.

Another thing I've observed while using the winreg_SetValue call - I
could pass an utf8 string to the api while it says it requires utf16
string.

Why this is important - when the registry db inits, some values which
are default registry values for certain keys go in as utf8. I wonder
if the winreg_enumvalue api requires the strings in the tdb to be
utf16 too ?

regards,
Chetan S

Further to my mail this problem I observed in the latest Samba_3_0 branch code.

I tried enumerating with - "net rpc registry enumerate" call to
check the values for a given subkey, when I encountered the problem

I could view the values with a tdbdump of the registry.tdb, but they
never reached the client side properly.

regards,
Chetan S.

PGP SIGNED MESSAGE
Hash: SHA1

Chetan S wrote:
10/13/06, Chetan S <cshring (AT) gmail (DOT) comwrote:
>Hi All,
>>
>The winreg_enumvalue digs out values perfectly fine from the tdb and
>this is observed in the server side log.smbd. However on the rpc
>client side no value is listed. More importantly it receives junk.
>>
>The problem perhaps lies with the idl.

Jelmer and I have already talked about this. It's on the TD
list. it's not so much a problem with the IDL as with the generated
client code.

PGP SIGNATURE
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

5DiD864jxavdVfCMjXb3Is8=
=ATuS
PGP SIGNATURE

Hi, Chetan!

Fri, 13, 2006 at 06:50:30PM +0530, Chetan S wrote:
The winreg_enumvalue digs out values perfectly fine from the tdb and
this is observed in the server side log.smbd. However on the rpc
client side no value is listed. More importantly it receives junk.

Did you find out more about this? If not, then this bug
report is not really sufficient. We'd need more detailed
steps to reproduce and log files.

Another thing: Did you already succeed in getting
registry-defined shares in smbd running? I'm asking because
I really want that feature, I'm close to doing it very soon
:-)

Volker

PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)

UaWDgwKnge75hjuQcCk6gSc=
=Vwl
PGP SIGNATURE

Hi Volker,

11/17/06, Volker Lendecke <Volker.Lendecke (AT) sernet (DOT) dewrote:
Hi, Chetan!

Fri, 13, 2006 at 06:50:30PM +0530, Chetan S wrote:
The winreg_enumvalue digs out values perfectly fine from the tdb and
this is observed in the server side log.smbd. However on the rpc
client side no value is listed. More importantly it receives junk.

Did you find out more about this? If not, then this bug
report is not really sufficient. We'd need more detailed
steps to reproduce and log files.

I did find more about it. The problem is with the UTF-8 / UTF-16
strings that get passed around. Here's the error reported by ndr_pull
:

[2006/11/20 14:23:17, 10] (894)
rpc_api_pipe: Remote machine 127.0.0.1 pipe \winreg fnum 0x75ab
returned 216 bytes.
[2006/11/20 14:23:17, 3] (343)
ndr_pull_error(0): Bad array size 7 should exceed array length 12

The client code trips on the fact that the array size is less that the
actual length of the string. The tcp dump+smbd log shows that the
values data is passed from the server side.

Steps to reproduce :

1. There are default values that smbd loads into the registry tdb in
registry/reg_db.c. one of them is "DisplayName" which should have the
value "Event Log". Enumerating the Event log key should result in
displaying the values within the subkey

/net rpc registry enumerate
"HKLM\\SYSTEM\\CurrentControlSet\\Services\\Eventlo g"
-Uusername%password -d 10 2>smbclient_err.log

Expected output :
List of subkeys and values for the Eventlog key.

Actual output :
Nothing.

Client Error log (at -d 10) : smbclient_err.log line 3014 states the
ndr_pull check error.

Samba Server log ( at -d 10 ) : log.smbd line 4357 states that the
value was retrieved.

Another thing: Did you already succeed in getting
registry-defined shares in smbd running? I'm asking because
I really want that feature, I'm close to doing it very soon
:-)

Not really. Am entagled in trying to understand the problem. My
immediate fear was whether the data I write goes in right or not. Its
really tricky to understand if a write to the registry has worked if
you cannot enumerate the values. Although the crude way I employed
was to tdbdump and grep :)

The UTF-16 requirements of windows clients creeps into the code. And
interchangeably dealing with UTF-8/16 is a problem.

Another problem with the UTF-16 code is the conversion routine
convert_string_allocate I haven't had much success converting a
CH_UNIX / CH_UTF8 string to UTF-16. The function returns a truncated
value.

Volker

Please let me know if you need any more information.

regards,
Chetan Shringarpure

Mon, Nov 20, 2006 at 02:44:58PM +0530, Chetan S wrote:
./net rpc registry enumerate
"HKLM\\SYSTEM\\CurrentControlSet\\Services\\Eventlo g"
-Uusername%password -d 10 2>smbclient_err.log

Expected output :
List of subkeys and values for the Eventlog key.

Actual output :
Nothing.

, got it. Thanks, looking at it now.

Volker

PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)

9lzZJBpFeygTcH6UPZYuhZk=
=+Uje
PGP SIGNATURE

Mon, Nov 20, 2006 at 02:44:58PM +0530, Chetan S wrote:
I did find more about it. The problem is with the UTF-8 / UTF-16
strings that get passed around. Here's the error reported by ndr_pull
:

See r19803, this fixes it for me.

>Another thing: Did you already succeed in getting
>registry-defined shares in smbd running? I'm asking because
>I really want that feature, I'm close to doing it very soon
>:-)

Not really. Am entagled in trying to understand the problem. My
immediate fear was whether the data I write goes in right or not. Its
really tricky to understand if a write to the registry has worked if
you cannot enumerate the values. Although the crude way I employed
was to tdbdump and grep :)

The UTF-16 requirements of windows clients creeps into the code. And
interchangeably dealing with UTF-8/16 is a problem.

Another problem with the UTF-16 code is the conversion routine
convert_string_allocate I haven't had much success converting a
CH_UNIX / CH_UTF8 string to UTF-16. The function returns a truncated
value.

Need to look at that more, but thanks for the heads-up.

Volker

PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)

xxXK3dJz5lZZSYxiEUM0k=
=y9++
PGP SIGNATURE

Hi Volker,

11/20/06, Volker Lendecke <Volker.Lendecke (AT) sernet (DOT) dewrote:
Mon, Nov 20, 2006 at 02:44:58PM +0530, Chetan S wrote:
I did find more about it. The problem is with the UTF-8 / UTF-16
strings that get passed around. Here's the error reported by ndr_pull
:

See r19803, this fixes it for me.

Thanks for the fix !

Works for me too. However, still, the reg types are not pulled
properly by client code. Mb'e another bug-hunt in sight :)

Seems like the shift to ndr based winreg rpc broke quite a few things around.

regards,
Chetan Shringarpure