Bug 8 - "rpcclient enumprinters" is broken
"rpcclient enumprinters" is broken
Status: RESOLVED WORKSFORME
Product: Samba 2.2
Classification: Unclassified
Component: rpcclient
2.2.8a
All Linux
: P2 normal
: ---
Assigned To: Tim Potter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-27 02:11 UTC by Gerald (Jerry) Carter
Modified: 2009-05-25 10:58 UTC (History)
0 users

See Also:


Attachments
original message about the bug (14.10 KB, text/plain)
2003-04-27 02:11 UTC, Gerald (Jerry) Carter
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald (Jerry) Carter 2003-04-27 02:11:00 UTC
From Kurt Pfeifle <kpfeifle@danka.de>

this is what I am finding with "rpcclient enumprinters" and "rpcclient
enumdrivers". It wasn't working in all levels in previous Samba versions for
me either, but 2.2.8a seems to have it broken worse than it was before. The
consequence: "cupsaddsmb" doesn't succeed any more with 2.2.8a.

Executive Summary:
------------------
* "cupsaddsmb" doesn't work, because....
* "rpcclient enumprinters" doesn't work in all levels -- some give segfaults
* "rpcclient enumdrivers" doesn't work in all levels -- some give segfaults

System overview:
----------------
SuSE-8.0, CUPS-1.1.19rc2, Samba-2.2.8a (with CUPS support compiled in),
currently only the driver "PDFcreator2" exported to Samba via "cupsaddsmb".
Comment 1 Gerald (Jerry) Carter 2003-04-27 02:11:58 UTC
Created attachment 2 [details]
original message about the bug
Comment 2 Gerald (Jerry) Carter 2003-04-27 02:26:04 UTC
On Sun, 6 Apr 2003, Nicholas Brealey <nick@brealey.org> wrote:

> Hello
>
> Replying to my own post. The same problem occurred in HEAD and 
> 3.0 and was fixed, see:
>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=b16d5s%24oq2%241%40FreeBSD.csie.NCT$
>
> The patch was:
>
http://cvs.samba.org/cgi-bin/cvsweb/samba/source/lib/util_unistr.c.diff?r1=1.97&r2=1.98
>
> I applied as similar patch and avoided the crash.
>
> I now get:
>
> rpcclient $> getdriver hplt2
>
> [Windows NT x86]
> Printer Driver Info 3:
>           Version: [2]
>           Driver Name: [HP LaserJet 2200 Series PS]
>           Architecture: [Windows NT x86]
>           Driver Path: [\\xxxxxxx\print$\W32X86\2\PSCRIPT4.DLL]
>           Datafile: [\\xxxxxxx\print$\W32X86\2\HP2200_6.PPD]
>           Configfile: [\\xxxxxxx\print$\W32X86\2\PS4UI.DLL]
>           Helpfile: [\\xxxxxxx\print$\W32X86\2\PSCRIPT4.HLP]
>
>           Dependentfiles: [\\xxxxxxx\print$\W32X86\2\HPBHEALR.DLL]
>           Dependentfiles: [\\xxxxxxx\print$\W32X86\2\HPDOMON.DLL]
>           Dependentfiles: [\\xxxxxxx\print$\W32X86\2\HPBMMON.DLL]
>           Dependentfiles: [\\xxxxxxx\print$\W32X86\2\PSCRIPT.NTF]
>
>           Monitorname: [HP Master Monitor]
>           Defaultdatatype: [^_]
>
> I don't know what the ^_ means.
Comment 3 Tim Potter 2003-04-27 14:18:56 UTC
Assigning to me.
Comment 4 Tim Potter 2003-04-28 12:27:00 UTC
The ^_ is some representation of a ^C character that somehow made it into the
problem description.  If you run the output of a getdriver command through less
you will see a ^C character.
Comment 5 Tim Potter 2003-04-28 13:25:00 UTC
There's actually some bug in the unmarshalling of a null relstr (when the offset
is 0).  The Samba client code always returns one junk character which I am
seeing as a ^C.  

The usual fix for this problem is to either apply the util_unistr.c patch:

diff -u -r1.97 -r1.98
--- samba/source/lib/util_unistr.c	2002/11/08 18:44:57	1.97
+++ samba/source/lib/util_unistr.c	2003/01/29 02:55:39	1.98
@@ -169,6 +169,7 @@
  */ 
 int rpcstr_pull(char* dest, void *src, int dest_len, int src_len, int flags)
 {
+	if (!src) return 0;
 	if(dest_len==-1) dest_len=MAXUNI-3;
 	return pull_ucs2(NULL, dest, src, dest_len, src_len,
flags|STR_UNICODE|STR_NOALIGN);
 }

or to check if the unistr buffer is NULL before calling rpcstr_pull():

Index: rpcclient/cmd_spoolss.c
===================================================================
RCS file: /data/cvs/samba/source/rpcclient/cmd_spoolss.c,v
retrieving revision 1.33.2.34
diff -u -r1.33.2.34 cmd_spoolss.c
--- rpcclient/cmd_spoolss.c	4 Mar 2003 23:35:58 -0000	1.33.2.34
+++ rpcclient/cmd_spoolss.c	28 Apr 2003 03:24:21 -0000
@@ -670,8 +670,8 @@
 	fstring configfile;
 	fstring helpfile;
 	fstring dependentfiles;
-	fstring monitorname;
-	fstring defaultdatatype;
+	fstring monitorname = "";
+	fstring defaultdatatype = "";
 	
 	int length=0;
 	BOOL valid = True;
@@ -685,8 +685,10 @@
 	rpcstr_pull(datafile, i1->datafile.buffer, sizeof(datafile), 0, STR_TERMINATE);
 	rpcstr_pull(configfile, i1->configfile.buffer, sizeof(configfile), 0,
STR_TERMINATE);
 	rpcstr_pull(helpfile, i1->helpfile.buffer, sizeof(helpfile), 0, STR_TERMINATE);
-	rpcstr_pull(monitorname, i1->monitorname.buffer, sizeof(monitorname), 0,
STR_TERMINATE);
-	rpcstr_pull(defaultdatatype, i1->defaultdatatype.buffer,
sizeof(defaultdatatype), 0, STR_TERMINATE);
+	if (i1->monitorname.buffer)
+		rpcstr_pull(monitorname, i1->monitorname.buffer, sizeof(monitorname), 0,
STR_TERMINATE);
+	if (i1->defaultdatatype.buffer)
+		rpcstr_pull(defaultdatatype, i1->defaultdatatype.buffer,
sizeof(defaultdatatype), 0, STR_TERMINATE);
 
 	printf ("Printer Driver Info 3:\n");
 	printf ("\tVersion: [%x]\n", i1->version);

We should probably fix the unistr unmarshalling bug in head.  Jerry, what do you
think?
Comment 6 Gerald (Jerry) Carter 2005-11-14 09:28:12 UTC
database cleanup
Comment 7 Volker Lendecke 2009-05-25 10:58:13 UTC
Closing, the code has changed significantly in between. Jerry, please re-open if this is still an issue with the latest code.

Volker