Bug 4655 - "rpcclient enumdataex" is broken
Summary: "rpcclient enumdataex" is broken
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.0.24
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-24 04:27 UTC by Sidney Däbler
Modified: 2007-05-24 15:40 UTC (History)
0 users

See Also:


Attachments
Patch (2.70 KB, patch)
2007-05-24 15:38 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sidney Däbler 2007-05-24 04:27:55 UTC
environment:
- printer share on windows server 2k3 / windows xp (tested with hp laserjet 5 and hp color laserjet 4600)
- debian etch with samba 3.0.24

"rpcclient -U [user] -c 'enumdataex [printer] DsDriver' [server]" gives:

--- snip ---
printMaxXExtent: REG_DWORD: 0x086f0000
intMaxYExtent: REG_DWORD: 0x00000de4
printMinXExtent: REG_DWORD: 0x00000379
printMinYExtent: REG_MULTI_SZ:
  Ø¿
  rintMediaSupported
  Letter
  Legal
  Executive
--- snip ---

this should be:

--- snip ---
printMaxXExtent: REG_DWORD: 0x0000086f
printMaxYExtent: REG_DWORD: 0x00000de4
printMinXExtent: REG_DWORD: 0x00000379
printMinYExtent: REG_DWORD: 0x0000063f
printMediaSupported: REG_MULTI_SZ:
  Letter
  Legal
  Executive
  A4
  A5
--- snip ---

the function spoolss_io_printer_enum_values_ctr in source/rpc_parse/parse_spoolss.c doesn't handle the rpc response correctly.
 
possible patch:

--- samba-3.0.24.orig/source/rpc_parse/parse_spoolss.c  2007-02-04 19:59:22.000000000 +0100
+++ samba-3.0.24/source/rpc_parse/parse_spoolss.c       2007-05-24 10:39:31.000000000 +0200
@@ -6942,19 +6942,11 @@
        uint32  valuename_offset,
                data_offset,
                current_offset;
-       const uint32 basic_unit = 20; /* size of static portion of enum_values */
 
        prs_debug(ps, depth, desc, "spoolss_io_printer_enum_values_ctr");
        depth++;
 
-       /* 
-        * offset data begins at 20 bytes per structure * size_of_array.
-        * Don't forget the uint32 at the beginning 
-        * */
-
-       current_offset = basic_unit * ctr->size_of_array;
-
-       /* first loop to write basic enum_value information */
+       current_offset = ps->data_offset;
 
        if (UNMARSHALLING(ps)) {
                ctr->values = PRS_ALLOC_MEM(ps, PRINTER_ENUM_VALUES, ctr->size_of_array);
@@ -6963,39 +6955,28 @@
        }
 
        for (i=0; i<ctr->size_of_array; i++) {
-               valuename_offset = current_offset;
                if (!prs_uint32("valuename_offset", ps, depth, &valuename_offset))
                        return False;
+               valuename_offset += current_offset;
 
                if (!prs_uint32("value_len", ps, depth, &ctr->values[i].value_len))
                        return False;
-
+
                if (!prs_uint32("type", ps, depth, &ctr->values[i].type))
                        return False;
-
-               data_offset = ctr->values[i].value_len + valuename_offset;
-
+
                if (!prs_uint32("data_offset", ps, depth, &data_offset))
                        return False;
+               data_offset += current_offset;
 
                if (!prs_uint32("data_len", ps, depth, &ctr->values[i].data_len))
                        return False;
-
-               current_offset  = data_offset + ctr->values[i].data_len - basic_unit;
-               /* account for 2 byte alignment */
-               current_offset += (current_offset % 2);
-       }
-       /* 
-        * loop #2 for writing the dynamically size objects; pay 
-        * attention to 2-byte alignment here....
-        */
-
-       for (i=0; i<ctr->size_of_array; i++) {
-
+               ps->data_offset = valuename_offset;
                if (!prs_unistr("valuename", ps, depth, &ctr->values[i].valuename))
                        return False;
-
+
+               ps->data_offset = data_offset;
                if ( ctr->values[i].data_len ) {
                        if ( UNMARSHALLING(ps) ) {
                                ctr->values[i].data = PRS_ALLOC_MEM(ps, uint8, ctr->values[i].data_len);
@@ -7005,9 +6986,9 @@
                        if (!prs_uint8s(False, "data", ps, depth, ctr->values[i].data, ctr->values[i].data_len))
                                return False;
                }
-
-               if ( !prs_align_uint16(ps) )
-                       return False;
+
+               current_offset += sizeof(PRINTER_ENUM_VALUES);
+               ps->data_offset = current_offset;
        }
 
        return True;
Comment 1 Jeremy Allison 2007-05-24 13:43:01 UTC
Reproduced this - I'll look at the patch - thanks. Too late for 3.0.25a.
This will be targeted for 3.0.25b (if we do such a release) or 3.0.26.

Thanks,

Jeremy.
Comment 2 Jeremy Allison 2007-05-24 15:38:28 UTC
Created attachment 2728 [details]
Patch

Your patch gave me a clue, but would have broken the server marshalling of the data. The attached patch should fix things without breaking server marshalling.
Too late for 3.0.25a, will be 25b or 26.
Jeremy.
Comment 3 Jeremy Allison 2007-05-24 15:40:59 UTC
Fixed with attached patch.
Jeremy.