Bug 3396 - rpcclient generates invalid RPC SPOOLSS AddPrinterEx requests
rpcclient generates invalid RPC SPOOLSS AddPrinterEx requests
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Printing
3.0.20b
x86 Linux
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-11 17:29 UTC by Marc Bevand
Modified: 2007-03-19 12:46 UTC (History)
0 users

See Also:


Attachments
Capture of network traffic showing the error reply to an AddPrinterEx request (7.12 KB, application/octet-stream)
2006-01-25 10:41 UTC, Marc Bevand
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Bevand 2006-01-11 17:29:19 UTC
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...
Comment 1 Marc Bevand 2006-01-24 18:45:13 UTC
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.
Comment 2 Gerald (Jerry) Carter 2006-01-24 20:01:27 UTC
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.
Comment 3 Marc Bevand 2006-01-25 10:41:35 UTC
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.
Comment 4 Gerald (Jerry) Carter 2006-03-16 07:27:02 UTC
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 ?
Comment 5 Marc Bevand 2006-03-16 15:07:08 UTC
(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).
Comment 6 Gerald (Jerry) Carter 2006-03-16 15:30:55 UTC
ok.  But the trace shows the target server as Windows 2000.
Comment 7 Marc Bevand 2006-03-16 16:59:57 UTC
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).
Comment 8 Gerald (Jerry) Carter 2007-03-19 12:46:54 UTC
Please retest against 3.0.25pre2 as we have some fixes that I think
might address this.