Bug 2723 - Windows sends SMB packets in non-sequential order
Windows sends SMB packets in non-sequential order
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Printing
3.0.9
All Windows XP
: P3 major
: none
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
anonymous FTP on aftp.efi.com /tmp/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-17 11:51 UTC by Arcady Chernyak
Modified: 2005-08-24 10:27 UTC (History)
1 user (show)

See Also:


Attachments
Plain text export from ethereal capture file (45.66 KB, text/plain)
2005-05-17 11:58 UTC, Arcady Chernyak
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arcady Chernyak 2005-05-17 11:51:48 UTC
I have found that when Windows spooler sends print file to SAMBA it 
may send packets with non-sequential order but with correct offsets. 
Samba supports non-sequential SMB offset for file shares well, but 
doesn't support it at all for the SMB printing. I guess that this is 
the critical bug because sometimes Windows sends print file in "out of 
order" SMB blocks.
It proves by Ethereal captures were we can see SMB blocks sent to print share 
out of sequential order.
How to reproduce it:
I have prepared special file with running ASCI number and copy this file to 
Samba print share. I have made empty "print command" for keeping this file in 
spool directory. I have calculated MD5 sum for the Linux and Window copy of 
this file. Sometimes it's differnt, and in this case you can see that two data 
block were swapped. I have made a capture (by ethereal) and found that it 
happen on wire (Windows did it). Samba never supports out of order SMB block 
for printing. I beleive it's mandatory.
Comment 1 Arcady Chernyak 2005-05-17 11:58:25 UTC
Created attachment 1233 [details]
Plain text export from ethereal capture file

There are 4 sequential write requests with out of order offsets.
File data has running ASCI numbers for simple calculation were swap was.
Comment 2 Jeremy Allison 2005-05-17 12:03:49 UTC
No no no!!!! This is completely and utterly USELESS !!!!
Please attach the *RAW* ethereal capture data. The text output is worse than
useless. If it's too big send it to me directly or make it available over the
web. People, *PLEASE NEVER SEND TEXT CAPTURE FILES* !! What do you think we can
do with them ?
Jeremy.
Comment 3 Gerald (Jerry) Carter 2005-05-30 19:47:19 UTC
jeremy,  if the fix you checked in is complete, please close this bug.  thanks.
Comment 4 Jeremy Allison 2005-05-31 08:52:05 UTC
I think this bug is now fixed in SVN.
Jeremy.
Comment 5 Gerald (Jerry) Carter 2005-08-24 10:27:34 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.