Hi, I am using Samba 3.0.20b (latest version packaged by Gentoo Linux), and it seems that rpcclient(1), when used with the arguments "-c 'addprinter ...'", always fails with a WERR_GENERAL_FAILURE error. I have tracked down the issue with Ethereal and rpcclient apparently generates an invalid NDR encoding for the RPC SPOOLSS AddPrinterEx request. Here is what I tried (I have simplified the example to demonstrate the bug, I am not actually expecting the following command to do anything useful): $ rpcclient -d 3 -U administrator \ -c 'addprinter my_printer my_share drivername LPT1' 10.68.11.4 added interface ip=192.168.101.42 bcast=192.168.101.255 nmask=255.255.255.0 added interface ip=10.68.11.1 bcast=10.68.11.255 nmask=255.255.255.0 lp_load: refreshing parameters Initialising global parameters params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf" Processing section "[global]" Password: Connecting to host=10.68.11.4 Connecting to 10.68.11.4 at port 445 Doing spnego session setup (blob length=16) server didn't supply a full spnego negprot Got challenge flags: Got NTLMSSP neg_flags=0x608a0215 NTLMSSP: Set final flags: Got NTLMSSP neg_flags=0x60080215 NTLMSSP Sign/Seal - Initialising with flags: Got NTLMSSP neg_flags=0x60080215 lsa_io_sec_qos: length c does not match size 8 result was WERR_GENERAL_FAILURE See the end of this email for an Ethereal network traffic capture showing the two interesting packets (RPC request and response). As we can see, the server replies with 'nca_s_fault_ndr' which, to the best of my knowledge, indicates the NDR encoding of the RPC request is invalid. I have included an hexadecimal dump of the RPC request stub data (that is the data appearing immediately after the 16-bit RPC operation number which is 0x46 for AddPrinterEx). These stub data correspond to the NDR encoding of AddPrinterEx's arguments. The IDL definition of this operation is (see spoolss.idl): WERROR spoolss_AddPrinterEx( [in] [string,charset(UTF16)] uint16 *server, [in] uint32 level, [in,switch_is(level)] spoolss_PrinterInfo *info, [in] spoolss_DevmodeContainer devmode_ctr, [in] security_descriptor *secdesc, [in] uint32 ulevel, [in,switch_is(ulevel)] spoolss_UserLevel userlevel ); If we start to manually decode the stub data (see the end of this email), we clearly see the pointer to the conformant and varying string 'server', that is: 0x801eea40 referent id 0x0000000c maximum count 0x00000000 offset 0x0000000c actual count 5c00 5c00 3100 3000 2e00 3600 3800 2e00 3100 3100 2e00 3400 string Etc. I am not an NDR expert, but it seems that the packet is conformant to the definition given in the IDL file. So I am wondering: do you think the spoolss.idl file might incorrectly defines the AddPrinterEx operation ? Thanks. --- RPC request --- No. Time Source Destination Protocol Info 29 0.088393 10.68.11.1 10.68.11.4 SPOOLSS AddPrinterEx request Frame 29 (684 bytes on wire, 684 bytes captured) Ethernet II, Src: 3e:e1:20:fd:bf:df (3e:e1:20:fd:bf:df), Dst: RealtekU_12:34:56 (52:54:00:12:34:56) Internet Protocol, Src: 10.68.11.1 (10.68.11.1), Dst: 10.68.11.4 (10.68.11.4) Transmission Control Protocol, Src Port: 35280 (35280), Dst Port: microsoft-ds (445), Seq: 1705, Ack: 1641, Len: 618 NetBIOS Session Service SMB (Server Message Block Protocol) SMB Pipe Protocol DCE RPC Request, Fragment: Single, FragLen: 532, Call: 6 Ctx: 0, [Resp: #30] Version: 5 Version (minor): 0 Packet type: Request (0) Packet Flags: 0x03 Data Representation: 10000000 Frag Length: 532 Auth Length: 0 Call ID: 6 Alloc hint: 516 Context ID: 0 Opnum: 70 Response in frame: 30 Microsoft Spool Subsystem, AddPrinterEx Operation: AddPrinterEx (70) Stub data (508 bytes) --- RPC response --- No. Time Source Destination Protocol Info 30 0.089882 10.68.11.4 10.68.11.1 DCERPC Fault: call_id: 6 ctx_id: 0 status: nca_s_fault_ndr Frame 30 (158 bytes on wire, 158 bytes captured) Ethernet II, Src: RealtekU_12:34:56 (52:54:00:12:34:56), Dst: 3e:e1:20:fd:bf:df (3e:e1:20:fd:bf:df) Internet Protocol, Src: 10.68.11.4 (10.68.11.4), Dst: 10.68.11.1 (10.68.11.1) Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: 35280 (35280), Seq: 1641, Ack: 2323, Len: 92 NetBIOS Session Service SMB (Server Message Block Protocol) SMB Pipe Protocol DCE RPC Fault, Fragment: Single, FragLen: 32, Call: 6, [Req: #29] Version: 5 Version (minor): 0 Packet type: Fault (3) Packet Flags: 0x03 Data Representation: 10000000 Frag Length: 32 Auth Length: 0 Call ID: 6 Alloc hint: 0 Context ID: 0 Cancel count: 0 Status: nca_s_fault_ndr (0x000006f7) Opnum: 70 Request in frame: 29 Time from request: 0.001489000 seconds --- Stub data --- 0000000: 40ea 1e80 0c00 0000 0000 0000 0c00 0000 @............... 0000010: 5c00 5c00 3100 3000 2e00 3600 3800 2e00 \.\.1.0...6.8... 0000020: 3100 3100 2e00 3400 0200 0000 0200 0000 1.1...4......... 0000030: 0100 0000 0000 0000 0100 0000 0100 0000 ................ 0000040: 0100 0000 0100 0000 0100 0000 0000 0000 ................ 0000050: 0000 0000 0000 0000 0100 0000 0100 0000 ................ 0000060: 0000 0000 0000 0000 0800 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 99b2 dff0 ................ 0000080: 0000 0000 0000 0000 0b00 0000 0000 0000 ................ 0000090: 0b00 0000 6d00 7900 5f00 7000 7200 6900 ....m.y._.p.r.i. 00000a0: 6e00 7400 6500 7200 0000 0000 0900 0000 n.t.e.r......... 00000b0: 0000 0000 0900 0000 6d00 7900 5f00 7300 ........m.y._.s. 00000c0: 6800 6100 7200 6500 0000 0000 0500 0000 h.a.r.e......... 00000d0: 0000 0000 0500 0000 4c00 5000 5400 3100 ........L.P.T.1. 00000e0: 0000 0000 0b00 0000 0000 0000 0b00 0000 ................ 00000f0: 6400 7200 6900 7600 6500 7200 6e00 6100 d.r.i.v.e.r.n.a. 0000100: 6d00 6500 0000 0000 1500 0000 0000 0000 m.e............. 0000110: 1500 0000 4300 7200 6500 6100 7400 6500 ....C.r.e.a.t.e. 0000120: 6400 2000 6200 7900 2000 7200 7000 6300 d. .b.y. .r.p.c. 0000130: 6300 6c00 6900 6500 6e00 7400 0000 0000 c.l.i.e.n.t..... 0000140: 0900 0000 0000 0000 0900 0000 7700 6900 ............w.i. 0000150: 6e00 7000 7200 6900 6e00 7400 0000 0000 n.p.r.i.n.t..... 0000160: 0400 0000 0000 0000 0400 0000 5200 4100 ............R.A. 0000170: 5700 0000 0000 0000 0000 0000 00d5 0d80 W............... 0000180: 00d5 0d80 0100 0000 0100 0000 08ee 1e80 ................ 0000190: 1d00 0000 50ee 1e80 80f6 2080 6505 0000 ....P..... .e... 00001a0: 0200 0000 0000 0000 0000 0000 0d00 0000 ................ 00001b0: 0000 0000 0d00 0000 5c00 5c00 3100 3000 ........\.\.1.0. 00001c0: 2e00 3600 3800 2e00 3100 3100 2e00 3400 ..6.8...1.1...4. 00001d0: 0000 0000 0e00 0000 0000 0000 0e00 0000 ................ 00001e0: 6100 6400 6d00 6900 6e00 6900 7300 7400 a.d.m.i.n.i.s.t. 00001f0: 7200 6100 7400 6f00 7200 0000 r.a.t.o.r...
It has been 2 weeks since I reported this bug, but no one has made a comment yet. Does it mean no one has a clue, hmm ? ;-) I might find some time to look into this issue in the near future, so even a simple comment "yes we are not 100% sure about our IDL file, it might be uncorrect" could help me a lot.
No. It just means that we have been busy working on other bugs. It you would attach a raw ethereal trace, I'll try to take a look. A text dump of the packets provides no help. Thanks.
Created attachment 1708 [details] Capture of network traffic showing the error reply to an AddPrinterEx request Here you go... 10.68.11.1 is the host sending an AddPrinterEx request to 10.68.11.4. The hex dump I provided in the bug description is a dump of packet #29 in this pcap file.
Finally got a chance to look at this. Our IDL is correct as far as we know. The server and client code is based on the same parsing routines and the server code works fine. The one things that appears strange in you trace is that the driver name in the request packet is "drivername". Have you modified the packet trace at all ?
(In reply to comment #4) > Finally got a chance to look at this. Our IDL is correct as > far as we know. The server and client code is based on the > same parsing routines and the server code works fine. > > The one things that appears strange in you trace is that > the driver name in the request packet is "drivername". > Have you modified the packet trace at all ? No the driver name is "drivername" because I specified it in the options. As you can see in the description of the bug, I used: $ rpcclient -d 3 -U administrator \ -c 'addprinter my_printer my_share drivername LPT1' 10.68.11.4 Oh and I forgot to include a very important piece of information: the request is sent to 10.68.11.4 which is a Windows XP SP1 box (NOT a samba server).
ok. But the trace shows the target server as Windows 2000.
Hmm. My memory is probably failing. If it's a Windows 2000, then it was 2000 SP4 (the main qemu system I was using at this time).
Please retest against 3.0.25pre2 as we have some fixes that I think might address this.