[cifs-protocol] [REG: 110021555999716 ] RE: Spoolss questions

Obaid Farooqi obaidf at microsoft.com
Fri Feb 19 15:14:37 MST 2010


Hi Mathieu:
I reproduced the problem to do debugging and I noted the following:

1. My trace (attached) also shows that XP client calls EnumForm after GetPrinterDriver2  (frame 453)
2. The driver download response in both of your traces seems to download driver from server. The driver looks different but that could be because servers are sending different stuff.
3. Both in my trace and your s3server_genericprinter trace, the time difference from GetPrinterdriver2 to EnumForms is 7-8 seconds. Your trace xpsever_genericprinter stops less than one second after GetPrinterDriver2. May be you stopped the trace too early in case of XP server?

Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft

-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba at matws.net] 
Sent: Wednesday, February 17, 2010 2:39 PM
To: Obaid Farooqi
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: Re: [REG: 110021555999716 ] RE: Spoolss questions

Hi Obaid,

Here it is:

on the "XP print server":

Create a printer with the Generic / text only driver Share it with the share name: test

On a another XP workstation:

Open the XP server (ie. \\1.2.3.4 in explorer) Double click on the printer to get it installed.

When doing this the driver is copied from the print server into the client (XP server case).
With S3 it starts to diverge after the client requested the level 101 on getprinterdriver (and when it got the answer back from the server).

That's this precise point where I want the explaination of what is missing in s3 answer to trigger the driver download (like it's the case when XP is acting like a print server).

Matthieu.
On 17/02/2010 19:12, Obaid Farooqi wrote:
> Hi Matthieu:
> Sorry for not being very clear. I already have your traces. What I want is the steps to reproduce this trace, meaning what program you ran on client and server to cause this message exchange. I am looking for step by step instructions so that I can reproduce this.
>
> Regards,
> Obaid Farooqi
> Sr. Support Escalation Engineer | Microsoft
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba at matws.net]
> Sent: Wednesday, February 17, 2010 1:13 AM
> To: Obaid Farooqi
> Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
> Subject: Re: [REG: 110021555999716 ] RE: Spoolss questions
>
> On 17/02/2010 03:50, Obaid Farooqi wrote:
>> Hi Mathew:
>> Please provide the detailed steps to get the capture http://www.matws.net/mat/misc/xpserver_genericprinter.
> It's a simple tcpdump capture just download it. I made a link with the .cap at the end so maybe it's easier like this on Windows:
> http://www.matws.net/mat/misc/xpserver_genericprinter.cap
> http://www.matws.net/mat/misc/s3server_genericprinter.cap
>
>> Please include the OS information with service packs applied as well.
> Os: Windows XP Pro SP2 for the XP workstations, Samba 3.5 git tree
>
> Matthieu.
>>
>> Regards,
>> Obaid Farooqi
>> Sr. Support Escalation Engineer | Microsoft
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat+Informatique.Samba at matws.net]
>> Sent: Sunday, February 14, 2010 3:26 PM
>> To: Interoperability Documentation Help; pfif at tridgell.net; 
>> cifs-protocol at samba.org
>> Subject: Spoolss questions
>>
>> Hello Dochelp Team,
>>
>> I've got a few questions regarding the MS-RPRN documentation, here they are:
>>
>> 1) Page 372 it is stated that :
>> "FeatureOptionPairs (variable): Must be a concatenation of an even number of zero-terminated ASCII strings, terminated by an additional zero character. Each pair of two consecutive strings specifies a print schema feature and the currently selected option."
>>
>> Which options should be included in this field ?
>> What is the signification of the options, for instance the dump of the Generic / Text only driver give the following array:
>>                                options: ARRAY(10)
>>                                    [0]                      : 'InputBin'
>>                                    [1]                      : 'Option1'
>>                                    [2]                      : 'RESDLL'
>>                                    [3]                      : 'UniresDLL'
>>                                    [4]                      : 'Resolution'
>>                                    [5]                      : 'Option1'
>>                                    [6]                      : 'PaperSize'
>>                                    [7]                      : 'LETTER'
>>                                    [8]                      : 'Orientation'
>>                                    [9]                      : 'PORTRAIT'
>>
>> For PaperSize and Orientation it's quite obvious but for InputBin 
>> RESDLL or Resolution it's already not
>>
>> 2) I have the impression that the definition of the JTEXP structure defined page 372 is not complete.
>> Because here is a dump of the whole extra data field:
>> 00000000  44 49 4e 55 22 00 b0 00  ec 02 00 00 ba 91 73 ca
>> |DINU".........s.|
>> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> |................|
>> 00000020  00 00 00 00 00 00 00 00  00 00 00 00 05 00 00 00
>> |................|
>> 00000030  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> |................|
>> 00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> |................|
>> *
>> 00000230  01 00 00 00 00 00 00 00  00 00 00 00 b0 00 00 00
>> |................|
>> 00000240  53 4d 54 4a 00 00 00 00  10 00 a0 00 47 00 65 00
>> |SMTJ........G.e.|
>> 00000250  6e 00 65 00 72 00 69 00  63 00 20 00 2f 00 20 00  |n.e.r.i.c.
>> ./. .|
>> 00000260  54 00 65 00 78 00 74 00  20 00 4f 00 6e 00 6c 00  |T.e.x.t.
>> .O.n.l.|
>> 00000270  79 00 00 00 49 6e 70 75  74 42 69 6e 00 4f 70 74
>> |y...InputBin.Opt|
>> 00000280  69 6f 6e 31 00 52 45 53  44 4c 4c 00 55 6e 69 72
>> |ion1.RESDLL.Unir|
>> 00000290  65 73 44 4c 4c 00 52 65  73 6f 6c 75 74 69 6f 6e
>> |esDLL.Resolution|
>> 000002a0  00 4f 70 74 69 6f 6e 31  00 50 61 70 65 72 53 69
>> |.Option1.PaperSi|
>> 000002b0  7a 65 00 4c 45 54 54 45  52 00 4f 72 69 65 6e 74
>> |ze.LETTER.Orient|
>> 000002c0  61 74 69 6f 6e 00 50 4f  52 54 52 41 49 54 00 00
>> |ation.PORTRAIT..|
>> 000002d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> |................|
>> 000002e0  00 00 00 00 00 00 00 00  00 00 00 00              |............|
>> 000002ec
>>
>> As the feature options pair is a null terminated array of null terminated string it seems to me that the end of the array is at 2cF and it leaves 28 bytes not used.
>> Am I wrong ?
>>
>> 3) Page 372 it is stated that:
>> "dwOptions: The value of this field must be the number of entries in the aOptions array that are initialized.
>> aOptions: This field is an array that is 512 bytes in length and contains user interface selections.
>> Unused fields should be initialized to zero. The meaning of the entries differs for each supported printer model. Upon receipt, the checksum of this array is computed and compared to dwChecksum32. The array is used only if the checksums match.
>> "
>>
>> A ndrdump of this part gives:
>>                        usedoptions              : 0x00000005 (5)
>>                        options: ARRAY(128)
>>                            options                  : 0x00000002 (2)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>                            options                  : 0x00000000 (0)
>>
>> where usedoptions is dwOptions and options is aOptions.
>>
>> The questions are: what is the meaning of an initialized entry in the aOptions array, because according to the dump we should have 5 initialized entries and we have only 1 with a non null value, and what is the signification of the value of the entry, is there a special meaning for each entry (ie. entry #1 is for the paper size, entry #2 is for the duplex capability) Also which checksum function is used how to compute it ? on which data ?
>>
>> 4) About level 101 of getprinterdriver We have currently a problem 
>> when replying correctly to level 101 request in getprinterdriver as 
>> the client is not downloading the drivers from the server, I made a 
>> test with a windows XP acting as a print server and in this case the 
>> client (also XP) is downloading the driver (see capture
>> http://www.matws.net/mat/misc/xpserver_genericprinter) after the getprinterdriver response.
>> In capture http://www.matws.net/mat/misc/s3server_genericprinter we can see that around packet 619, instead of requesting the drivers from the server (as it was the case for xp) the client is requesting forms.
>> Do you have an explanation for this ? what is needed as an answer from the server to trigger the driver download ?
>>
>>
>> Regards.
>> Matthieu.
>>
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: forMatthieu.zip
Type: application/x-zip-compressed
Size: 50774 bytes
Desc: forMatthieu.zip
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100219/766eba7b/attachment-0001.bin>


More information about the cifs-protocol mailing list