no document info sent to samba (was re: printing spool mods)

[Matt Chapman]

Andy Bakun wrote:

> I did do packet traces when printing from WinNT4 Workstation SP4 to
> Samba-2.0.0beta4 and from WinNT4 Workstation SP4 to WinNT4 Server SP4.  These
> are my findings.
>
> As far as I can tell, the client is NOT sending any information about the print
> job to Samba.  I chalked this up to an unknown SMB.  It just opens the file,
> sends data, and when the file is closed, samba queues it for printing.  If it
> used to work, as Andrew says, then I suspect it could be that it wants to use NT
> SMBs or something -- admittedly, this is half a wild guess and half an educated
> guess.

OK, I took some packet traces too.

Between the SMBopenAndX and SMBwrite Windows clients send an undocumented IOCTL
(device category 0x53, function 0x60). This is apparently to obtain a job
number, which is then sent to the server in the PrintJobInfo RAP.

[The IOCTL takes no parameters or data and returns a 32-byte data buffer:

USHORT jobno;
UCHAR server[15]; /* NETBIOS name of server, space padded */
UCHAR padding;
UCHAR service[];  /* ASCIIZ service name */
UCHAR garbage[];  /* Who said padding has to be zero? */ ]

Currently we fail this IOCTL with ERRSRV/ERRnosupport, which results in the
client aborting the PrintJobInfo request (as it failed to obtain a job number).

Returning success without providing the information results in a garbage job
number (which means that either Windows happily reads past the end of the
packet, or the variable is uninitialized...), but it's a valid workaround as
long as we are ignoring the job number in PrintJobInfo.

    Matt


--
Matt Chapman
m.chapman at student.unsw.edu.au