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;
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.
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.
Fixed with attached patch. Jeremy.